• These are very important and are used everywhere for scaling and security.

• We generally get confused between reverse and forward proxies.

Reverse Proxy

In simpler words - It sits between the internet and servers. So when someone outside (like a user browsing a website) wants to access a server, they first communicate with the reverse proxy, which then forwards their request to the appropriate server.

Eg. Think of a reverse proxy like a waiter in a busy restaurant. Instead of customers going to the kitchen to order food, they tell the waiter what they want, and the waiter takes their order to the kitchen for them. Similarly, a reverse proxy sits between people using a website (like customers in a restaurant) and the servers where the website is stored (like the kitchen), taking requests from users and passing them on to the servers.

Advantages

1. Load Balancing: As you can see in diagram Reverse Proxy can help in distributing traffic across multiple servers.

2. Security: Reverse proxy can inspect the request and can help in Filtering out the malicious traffic or enforcing security policies.

3. Cache: Frequently requested content can be cached by reverse proxy which helps in reducing the load at server.

4. SSL: At servers you don't need to understand the https that can be done at reverse proxy itself.

Nginx is one of the popular proxy server. Eg. with nginx

Forward Proxy

In simpler words - It sits between the client and the internet. When a client wants to access something on the internet, they communicate with the forward proxy first, which then fetches the requested information from the internet on behalf of the client.

Eg. In the days before direct dialing, telephone operators played a crucial role in connecting calls. When someone wanted to make a call, they would speak to the operator, who would then connect them to the desired number. The operator acted as a forward proxy, facilitating communication between callers and ensuring that calls reached their intended recipients.

Advantages

Anonymity: They can mask the IP addresses of clients, providing anonymity when accessing online resources.

Content Filtering: Forward proxies can block or filter specific types of content, such as malicious websites or inappropriate material, based on predefined policies.

Caching: Similar to reverse proxies, forward proxies can cache frequently requested content, reducing bandwidth usage and speeding up subsequent requests.

Access Control: They enable organizations to enforce access policies, restricting access to certain websites or services based on user credentials or permissions.

Squid is one of the popular forward proxy server.

Network Address Translation (NAT)

Lastly let's talk about NAT. Basically every device connected to a network requires a unique identifier to facilitate communication. NAT serves as the bridge between private internal networks and the public internet by translating between private IP addresses used within a local network and public IP addresses used on the internet.

NAT performs two primary functions:

1. Internet Access for Private Networks: NAT enables devices within a private network to access resources on the Internet. Devices within the private network are assigned private IP addresses, and the NAT device translates these private IP addresses to a single public IP address when communicating with external servers or services on the Internet.

2. Security: NAT provides a level of security by hiding the internal IP addresses of devices within the private network from external sources. When devices initiate connections to external servers or services, the external entities only see the public IP address assigned by the NAT device, helping to obscure the topology of the internal network and mitigate certain types of attacks.

3. Load Balancing: NAT can be used for load balancing traffic across multiple internal servers or services. In this scenario, incoming requests to a single public IP address are distributed across a pool of internal servers using different private IP addresses, based on predefined rules or algorithms.

4. IPv4 to IPv6 Translation

Forward Proxy and NAT (Network Address Translation) serve similar purposes in networking, but they operate at different layers of the OSI model and offer distinct functionalities.

I hope this is useful.

Suppose you have purchased the domain "example.com" from a domain provider. How can you configure it so that when someone visits example.com, it will reach your server?

You need to configure the DNS records.

DNS Records

What are DNS Records? - https://www.cloudflare.com/en-in/learning/dns/dns-records/ - DNS records are instructions that live in authoritative DNS servers and provide information about a domain including what IP address is associated with that domain and how to handle requests for that domain.

A Record / AAAA record

A Record - it's a mapping of the domain to the server's IPV4 address

AAAA Record - it's a mapping of the domain to the server's IPV6 address

1) Can I have multiple A-record for the same domain?

Yes, you can. It is called round-robin DNS, and the browser just chooses one of them randomly. It is a well-used method of getting cheap load balancing, but it has cons as well - i.e. one host goes down, users will still try to access it.

2) Can we point different IP Addresses to subdomains (www.example.com, blogs.example.com, labs.example.com) as well?

Yes, You can point the subdomain like www, labs etc. to a different IP address.

CNAME

A DNS CNAME record provides an alias for another domain. Here are the examples where it can help you

1) if Each subdomain points to the same server then you have two choices either write A record for each subdomain or set CNAME which points to the main domain

• www.example.com → example.com

• labs.example.com → example.com

The second approach is better to approach - let's say the server IP changes you don’t need to change anything other than A record i.e. example.com → 13.203.30.40

2) CNAME record also helps you in redirecting your page to some other website status.example.com → example.pageduty.com

NS Record

Nameserver is the server that stores A, AAAA, and CNAME records for your domain. NS Record helps you set up the right nameserver - Let’s say you are purchasing a domain from google and want to use Cloudflare then you can provide Cloudflare nameserver detail in the google domain. So you are trying to say that for looking for example.com detail please ask from Cloudflare nameserver.

Now let's understand what happens behind the scene when you hit example.com

When a user types example.com in a web browser, the browser checks its DNS cache to see if there is already an IP address mapping for the domain name. If there's no cache available, the browser calls the gethostbyname syscall to ask the operating system to find the IP address.

The operating system first looks at the /etc/nsswitch.conf (nameserver switch) file. It contains the following information:
hosts: files dns - This means that the OS will first look up the /etc/hosts file and then use the DNS protocol if it doesn't find an entry there.
If the /etc/hosts file has an entry 127.0.0.1 example.com then browser will call the IP address 127.0.0.1. if there is no entry then, it will first request the DNS server specified in the /etc/resolv.conf file. (If there's no response from that server, the OS will try the next IP address.)

So how does the DNS resolver find the IP address?
The DNS resolver first looks up its cache, which can be on various network devices. If there's no cache, it goes through the following steps:

The DNS server breaks down "example.com" into its parts.

• “.” → Root Server

  IP address of root server is known to DNS resolver and now it queries to root server to find the right IP of .com

• “.com” → TLD NameServer (top-level domain server)

  • DNS resolver now queries to .com server to return IP address of the authoritative nameserver of example.com

“example.com”

• now DNS resolver calls the authoritative nameserver of example.com to fetch the IP address of google.com

In summary, the DNS resolver uses a hierarchical system of servers to find the IP address associated with a domain name.

Shell Commands to experiments

#Run this command in one shell to capture all DNS requests
> sudo tcpdump -s 0 -A -i any port 53
# Make a dig request from another shell
> dig google.com

# tcpdump result
17:55:51.672393 IP 192.168.1.3.60562 > 192.168.1.1.domain: 64183+ [1au] A? google.com. (39)
D.;G*....,.C..E..C....@.4c...........5./W.... .........google.com.......)........
17:55:51.685685 IP 192.168.1.1.domain > 192.168.1.3.60562: 64183 1/0/1 A 142.250.77.238 (55)
...,.CD.;G*...E..SgE@.@.P..........5...?9|.............google.com...................M...)........


# Request made to 192.168.1.1.domain for google.com. 192.168.1.1.domain is the resolver mentioned in /etc/resolv.conf. Response received IP Address of google.com 142.250.77.238

> dig +trace google.com
google.com.   300      IN      A       142.250.193.46
request       ttl   class   type   response

> dig A facebook.com +short
157.240.239.35

> dig AAAA facebook.com +short
2a03:2880:f144:181:face:b00c:0:25de

> dig NS facebook.com +short
b.ns.facebook.com.
a.ns.facebook.com.
d.ns.facebook.com.
c.ns.facebook.com.

> dig www.facebook.com CNAME +short
star-mini.c10r.facebook.com.

ClickJacking

The victim visits the attacker's website and clicks on Play but actually, the victim clicks on Pay which is from the bank.com website.

The attacker has added the iframe of the bank.com website at the top z-index and made it transparent by setting opacity to 0. Play is just a simple component that is just below the iframe but it’s visible due to the iframe opacity being 0.

As a user, you shouldn’t visit any malicious sites and especially shouldn’t click anywhere. Users may use a different browser for using such websites which don’t have cookies of sites.

Cross-site Scripting Attack

Cross-Site Scripting (XSS) is a security vulnerability that allows an attacker to inject malicious scripts or code into a website, which can then be executed by unsuspecting users who visit the site. There are multiple ways through which this can happen

Reflected XSS

Step1 - Attacker share URL (which contains script)

Step2 - Victim clicks on the url

Step3 - Browser Request webserver

Step4 - Webserver return the page with the same script

Step5 - The script gets executed and the script starts sharing website data with attackers.

Stored XSS

Step1 - The attacker uploads script on the Website

Step2 - Website store the script

Step3 - Victim opens the website

Step4 - Webserver returns a page with the same script

Step5 - The browser executes the script and starts sharing user data with the Attacker.

Mime Sniffing Attack

MIME sniffing is a security vulnerability that can occur when a web browser attempts to determine the correct MIME type (file type) of a resource based on its content, rather than relying on the server-provided Content-Type header.

For example, an attacker could upload a malicious script to a website with a fake file extension that looks harmless (such as a .jpg or .gif file) but contains JavaScript code. If the server does not properly set the Content-Type header, the browser may attempt to "sniff" the file type and execute the script, allowing the attacker to execute arbitrary code or steal sensitive information.

Cross-Site WebSocket Hijacking

Cross-Site WebSocket Hijacking (CSWSH) is a type of attack that exploits WebSocket connections to allow an attacker to execute arbitrary code or steal sensitive information from a victim's browser.

Security Practices can prevent these attacks

Add HTTP Response Header - X-Frame-Options

Web developers can use the X-Frame-Options header to instruct the browser not to display their website in an iframe. The header can be set to one of three values: "DENY", "SAMEORIGIN", or "ALLOW-FROM uri".

X-Frame-Options: SAMEORIGIN

This prevents ClickJacking attacks.

Add HTTP Response Header - Content-Security-Policy

Content Security Policy (CSP) can use to control which resources (such as images, scripts, stylesheets, and fonts) are allowed to be loaded by their web application on the browser.

Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline' https://example.com;

This prevents Cross Site Scripting attacks.

Add HTTP Response Header - X-Content-Type-Option

The X-Content-Type-Options header guide browser on whether it should determine the mime type automatically or not.

By setting the header to "nosniff" developers can ensure that the browser always uses the specified MIME type, and prevent attackers from exploiting vulnerabilities that rely on MIME sniffing.

X-Content-Type-Options: nosniff

This prevents Mime Sniffing attacks.

Add HTTP Response Header - Referer Policy

The browser sends referer information to a new page/site when the user navigates to a new page. This feature can lead to security issues For example if a website has a lax Referer Policy that allows the Referer header to be sent to all third-party sites, an attacker could potentially use this information to track users across multiple sites or to collect sensitive information about the user's browsing habits.

By setting an appropriate Referer Policy, website owners can reduce the risk for users:

1. no-referrer: This value tells the browser not to send the Referer header at all when navigating to another website. This means that the target website will not know which page the user came from.

2. no-referrer-when-downgrade: This value tells the browser to send the Referer header when navigating to a website that uses HTTPS, but not when navigating to a website that uses HTTP.

3. same-origin: This value tells the browser to send the Referer header only when navigating to another page on the same origin (i.e., same scheme, hostname, and port).

4. strict-origin: This value tells the browser to send the Referer header when navigating to a page on the same origin, but not when navigating to a different origin.

5. origin: This value tells the browser to send the Referer header with just the scheme, hostname, and port of the referring page, but not the path or query string.

6. strict-origin-when-cross-origin: This value is similar to strict-origin, but it allows the Referer header to be sent when navigating from one origin to another if and only if the HTTP method is safe (i.e., GET, HEAD, or OPTIONS).

Always do WebSocket Origin Validation

Cross-Origin Validation is not being done by the browser when it's WebSocket connection. And hence Validating the origin of WebSocket connections is an important security measure to prevent unauthorized access and protect against Cross-Site WebSocket Hijacking (CSWSH) attacks.

If the server does not validate the Origin header, an attacker could potentially use a malicious webpage to establish a WebSocket connection to the server and execute arbitrary code or steal sensitive information.

Reference

If you're working on a microservices architecture with multiple services and would like to expose your APIs to external developers, several requirements need to be considered.

These requirements include

1. Authentication: Authentication is the process of verifying the identity of the user or system trying to access the APIs. An API gateway can apply authentication mechanisms such as OAuth2, JWT, or API keys to ensure that only authorized users or systems can access the APIs.

2. Rate Limitation: Rate limitation is the process of limiting the number of requests that a user or system can make to the APIs within a certain time period. An API gateway can enforce rate limits on a per-user or per-service basis to prevent overload on the underlying microservices.

3. Transformations on the request/response layer: Transformations on the request/response layer involve modifying or transforming the incoming requests and outgoing responses to the APIs. An API gateway can apply transformations such as message routing, filtering, content-based routing, or payload modification to ensure that the requests and responses are in the expected format and are compatible with the underlying microservices.

4. Different quotas based on developer types: Different quotas based on developer types involve setting different limits on the number of requests or resources that a user or system can access based on their membership level. An API gateway can provide different quotas for standard developers and premium developers, for example, by limiting the number of requests, the amount of data retrieved, or the frequency of API calls.

5. Different APIs are exposed based on developer types: Different APIs exposed based on developer types involve providing different sets of APIs to different users or systems based on their membership level. An API gateway can expose different APIs for standard developers and premium developers, for example, by hiding some APIs from standard developers and exposing more APIs to premium developers. This can be useful in monetizing the APIs and providing different levels of service to different customers.

6. Customize API that can mix all microservices complex logics and return output to make the external developer's life easier. In a microservices architecture, there may be several services that an external developer needs to access in order to complete a task. For example, a developer may need to interact with one service to retrieve user data, another service to retrieve product information, and yet another service to complete a transaction. To simplify this process, an API gateway can be configured to expose a separate API that combines all microservices and returns output to external developers. This separate API acts as a facade, hiding the complexities of the microservices architecture from external developers and providing a simpler interface for them to use. The API gateway takes care of routing requests to the appropriate microservices and aggregating their responses into a single output. This means that external developers can interact with a single endpoint and receive the necessary information from all the connected microservices.

To fulfill these requirements, an API gateway can be used to securely expose your APIs to external developers. By using an API gateway, internal services do not need to write these logics at their end. Instead, the API gateway will take care of all the requirements, such as managing authentication and rate limitations, applying transformations on the request/response layer, and providing different quotas and APIs based on the developer's type.

API Gateway can also perform additional functions, such as caching, logging, and monitoring. In addition, API Gateway provides API lifecycle management, which includes tasks such as creating, testing, deploying, versioning, and retiring APIs. By managing the API lifecycle in a centralized way, API Gateway can help ensure that APIs are developed, deployed, and retired consistently and in a controlled manner, reducing the risk of errors or security issues.

Understanding BFF

BFF, or Backend For Frontend, is an API gateway that is designed to serve front-end clients only. In a microservices architecture, there may be several internal services that a front-end or mobile application needs to access in order to create views that combine information from multiple services.

By introducing a BFF layer, you can take advantage of several benefits:

1. You can write all your front-end related logic in the BFF layer. This means that the internal microservices can remain focused on their core functionality, while the BFF handles any front-end-specific logic.

2. The BFF layer can act as a facade for the internal microservices, exposing a unified API that is tailored to the needs of the front-end application. This can simplify the front-end code and reduce the number of network requests needed to create a view.

3. You don't need to expose your internal services to the public. By routing all requests through the BFF layer, you can keep your internal services behind a firewall and only expose the BFF to the outside world.

4. Writing a BFF layer can help you manage authentication at the BFF level. While authorization may still need to be handled at the service level, the BFF layer can handle authentication for all requests, making it easier to manage security.

5. The BFF layer can also act as a filtering layer, allowing you to restrict which data is exposed to the front-end application. This can be particularly useful if your internal services expose data that should not be returned to front-end clients. By routing requests through the BFF, you can control which data is returned to the client, while still allowing internal services to function as intended.

One question that often comes up is whether introducing a BFF layer will create latency. While it is true that the BFF layer adds an extra hop in the request/response chain, the network latency can be reduced by batching multiple requests together and reducing the number of network calls that need to be made by the front-end application. Additionally, the BFF layer can cache responses and handle load balancing, further reducing latency and improving overall performance.

API-gateway vs BFF

API Gateway acts as a middleman between your internal microservices and external clients. Its main job is to provide a single interface for external clients to access your microservices while taking care of tasks like authentication, rate limiting, and routing requests to the right microservice. Additionally, API Gateway can perform other tasks like caching, logging, and monitoring.

BFF, on the other hand, sits between your internal microservices and your front-end clients, like mobile or web applications. Its main purpose is to simplify the front-end code by acting as a façade for your microservices and providing a tailored API that meets the needs of your front-end application.

In summary, while API Gateway is designed to handle external clients and provide a unified API to multiple types of clients, BFF is designed to handle front-end clients only and simplify the front-end code. Both API Gateway and BFF can help you manage and expose your microservices securely and efficiently, but they serve different purposes and are tailored to different types of clients.

References

https://samnewman.io/patterns/architectural/bff/#comment-2923121019

https://kuroco.app/blog/api-management/2022/05/05/api-gateway-vs-backend-for-frontend/

https://www.googlecloudcommunity.com/gc/Apigee/Can-we-get-rid-of-Backend-For-Frontend-when-using-an-API-Gateway/m-p/423745

https://medium.com/@abhilashjn85/bff-layer-when-its-more-than-just-an-api-gateway-4679da49534c