Technical Interview List - Network Edition

CORS (Cross-Origin Resource Sharing)

CORS is an HTTP header-based mechanism implemented for security when a web browser requests resources across different origins. By default, web browsers block requests for resources from different origins due to security issues. This restriction is known as the Same-Origin Policy, which limits requests coming from different domains, protocols, or ports.

Examples of Same-Origin Policy

Same origin: Sending a request from https://example.com/index.html to https://example.com/api/data

Different origin: Sending a request from https://example.com to https://api.anotherdomain.com (because the domains are different)

Key CORS Headers

Access-Control-Allow-Origin: Defines the allowed origin. Example: Access-Control-Allow-Origin: <https://example.com>

Access-Control-Allow-Methods: Defines the allowed HTTP methods. Example: GET, POST, PUT

Access-Control-Allow-Headers: Defines the allowed request headers. Example: Content-Type

Access-Control-Allow-Credentials: Indicates whether to allow requests that include credentials (cookies, authorization information, etc.)

CORS (Cross-Origin Resource Sharing) is a security policy that starts at the browser level. It checks whether the client (primarily the browser) is complying with the same-origin policy when requesting resources from the server, and it determines whether to allow or block requests based on the CORS headers provided by the server. This aspect is divided into roles and responsibilities between the server side and the client side (browser).

Client Side (Where CORS Operates) - Browser

When the browser tries to request resources from another origin, it checks the CORS rules.

If the server sends response headers to handle the CORS request, the browser verifies them.

If the server does not return appropriate CORS headers, the browser blocks access to the resource and displays a CORS error message in the console.

This is why you might see the error message "Blocked by CORS policy" in the browser developer tools console.

Thus, CORS itself is a policy where the client (browser) is responsible for checking whether it has permission from the server to access a specific resource. The browser enforces this policy, while the server supports it.

Server Side - Setting CORS Headers

The server has the authority to handle CORS requests and includes CORS-related headers in its response to inform the browser whether to allow requests from specific origins.

The server checks the CORS requests sent by the client, determines if the request is allowed, and responds by adding appropriate CORS headers. The server can allow or restrict the client's requests through various configurations.

If CORS is not set on the server side, the browser will block access to the resource. In other words, if the server does not send appropriate CORS headers, the browser prevents the use of resources from other origins for security reasons.

How CORS Works

CORS starts at the browser level. When accessing resources from another origin, the browser requests permission from the server based on the same-origin policy.

The server grants permission through its response. The server uses headers like Access-Control-Allow-Origin to inform the browser whether to allow the request.

The browser checks the CORS headers returned by the server. If the server allows the request, it can access the resource; if not, access is denied.

Thus, CORS is a security mechanism that operates through collaboration between the client (browser) and the server, but it originates from the browser, which decides the allowance based on the server's response.

Why Does It Start in the Browser Instead of the Server?

The key to this question lies in the fundamental operation of the web and security structure.

The Browser Must Control and Protect User Data

In web applications, the browser directly handles user data. This data can include session cookies, local storage, user information, etc. Therefore, the browser must control cross-origin requests to protect users' information from being unintentionally leaked or misused.

The Server is Simply a Resource Provider

The server's role is to provide resources. It can decide whether to allow the data or files requested by the client, but it does not control cross-origin requests, nor does it have the authority to dictate what resources the client can access.

The server must be able to respond even when unreliable requests are received, while the decision to restrict access to resources is made by the browser. The server can only signal that it will respond to requests from allowed origins.

Centralized Security Model

The reason CORS is enforced in the browser is that web security operates in a centralized model rather than a distributed one. The security of all web applications starts in the browser, not each server. The browser must have control to consistently block client-side attacks.

Preflight Requests

A Preflight request is an OPTIONS request that occurs only in specific cases of CORS. Before sending the main request, the browser checks with the server to see "if this request can be sent," and this is called a Preflight Request.

When Preflight Requests are Necessary

When the browser sends a CORS request to the server, a preflight check is needed if the request method or headers are considered unsafe. The conditions for unsafe requests are as follows:

The HTTP method used is not GET, HEAD, or POST (e.g., PUT, DELETE).

The request includes custom headers (e.g., X-Custom-Header).

The request's Content-Type is not application/json, multipart/form-data, etc.

Requests Considered Safe by the Browser (Can Proceed Without Preflight)

Methods: GET, POST, HEAD

Content-Type: text/plain, multipart/form-data, application/x-www-form-urlencoded

No custom headers, only headers automatically set by the browser

About CSRF

CSRF (Cross-Site Request Forgery) is one of the web security vulnerabilities where an attacker uses a trusted website to send an unintended request to the server on behalf of the user. In other words, the attacker exploits the user's credentials to send requests to the server, making the server process these requests as if they were legitimate user requests.

How CSRF Attacks Work

CSRF attacks typically occur in cases where session-based authentication is used in web applications. The core of the attack is the attacker using the user's authentication information to send requests to the server.

CSRF Attack Flow

The user logs into a website.

For example, the user logs into a bank website (e.g., bank.com) and has an active session. The user has an authenticated session cookie in the browser.

The attacker creates a manipulated webpage or link.

To exploit the logged-in state of the user, the attacker creates a manipulated link or form. For example, they lure the user to visit a website they created (e.g., evil.com).

When the user visits the manipulated page, it is set to send a specific request to bank.com.

The user visits the manipulated page.

The user clicks a link included in the email or a page created by the attacker and is directed to the manipulated page.

CSRF request is executed automatically.

As soon as the user visits the evil.com page, it automatically sends a request to bank.com. The crucial point is that the browser automatically sends the session cookie for bank.com. As a result, the server cannot determine if the request was sent by the user.

For example, a request to transfer money or change the password could be sent to bank.com.

The server processes the request.

The server processes the request without knowing it was manipulated by an attacker, because the user is already logged in. Consequently, the attacker's intended actions are executed on the server without the user's consent.

Methods to Defend Against CSRF Attacks

1. Use CSRF Tokens

A CSRF token is a unique token randomly generated by the server and provided to the client, which then sends it back to the server with each request. This token changes with each request and is unpredictable, making it effective against CSRF attacks.

When the server generates an HTML form, it adds the CSRF token as a hidden field.

The server stores the token in the session and compares it to the token received from the client. If they do not match, the request is rejected.

2. Use SameSite Cookie Attribute

The SameSite attribute controls whether cookies are sent with cross-site requests. By setting SameSite=Lax or SameSite=Strict, cookies will not be sent with cross-site requests, thereby preventing CSRF attacks.

SameSite=Lax: Cookies are included in normal browser navigation (like link clicks) across sites but not in form submissions or script requests.

SameSite=Strict: Cookies are not sent in any cross-site requests.

3. Validate the Referer Header

When a request is received, the server can inspect the Referer header to verify whether the request originated from the correct source (i.e., from the appropriate website). If the request comes from a different origin, it can be blocked.

This method is not foolproof

, as the Referer header can be manipulated, but it can add an extra layer of security.

Conclusion

Understanding CORS and CSRF is essential for web developers and frontend developers, as they ensure the security of web applications and protect against potential vulnerabilities. Being aware of the mechanisms, headers, and strategies for handling these security concerns is crucial for developing secure applications and safeguarding user data from threats on the web.

Interview Questions to Consider

What is CORS and how does it work?

Can you explain the Same-Origin Policy?

What are some common CORS headers?

When is a preflight request necessary?

What is CSRF and how does it work?

What are some techniques to prevent CSRF attacks?

Additional Concepts to Review

Network Protocols (HTTP/HTTPS)

Response Codes (2xx, 4xx, 5xx)

REST API Best Practices

Web Security Fundamentals

Prepare to articulate these concepts clearly and apply them in scenarios you might encounter during the interview. Good luck!