Web Security Essentials: SSRF, CSRF, and CORS Explained

In the modern web landscape, security is not just a feature—it’s a foundation. As applications become more interconnected, understanding the nuances of how requests are handled across different origins and servers is crucial for any developer.

Today, we’re diving into three critical concepts that every web developer should master: SSRF, CSRF, and CORS. While they might sound like alphabet soup, they represent the front lines of web application security.

1. SSRF (Server-Side Request Forgery)

SSRF is a vulnerability where an attacker can force a server-side application to make HTTP requests to an arbitrary domain of the attacker’s choosing.

How it Works

Imagine a web application that takes a URL as input (e.g., to fetch a profile picture or preview a link) and then makes a request to that URL from the server. If the application doesn’t properly validate this URL, an attacker could provide an internal IP address or a loopback address (127.0.0.1).

The server, acting as a proxy, might then fetch sensitive data from internal services that are not exposed to the public internet, such as:

• Cloud Metadata: Accessing 169.254.169.254 on AWS/GCP to retrieve IAM credentials.
• Internal Admin Panels: Accessing internal tools like Jenkins or Kubernetes dashboards.
• Port Scanning: Discovering other services running on the internal network.

Prevention

• Allowlisting: Only allow requests to a predefined list of trusted domains.
• Input Validation: Ensure the URL uses allowed protocols (e.g., https:// only) and doesn’t point to internal IP ranges.
• Network Segregation: Ensure the web server has restricted access to internal resources.

2. CSRF (Cross-Site Request Forgery)

CSRF is an attack that tricks a victim’s browser into performing an unwanted action on a different website where the victim is currently authenticated.

How it Works

This attack exploits the fact that browsers automatically include ambient credentials—like session cookies—with every request to a domain.

1. A user logs into bank.com.
2. The user visits a malicious site evil.com in another tab.
3. evil.com contains a hidden form that submits a POST request to bank.com/transfer?amount=1000&to=attacker.
4. The browser sends the request along with the user’s bank.com session cookie.
5. bank.com sees a valid session and processes the transfer.

Prevention

• Anti-CSRF Tokens: Include a unique, secret, and unpredictable token in every state-changing request. The server verifies this token before processing.
• SameSite Cookies: Set the SameSite attribute on cookies to Strict or Lax to prevent them from being sent on cross-site requests.
• Custom Headers: For AJAX requests, require a custom header (e.g., X-Requested-With) that cannot be set by a standard HTML form.

3. CORS (Cross-Origin Resource Sharing)

Unlike SSRF and CSRF, CORS is not a vulnerability itself, but a security mechanism. It’s a way for servers to tell the browser: “It’s okay for this specific outside origin to access my resources.”

Why it Exists

By default, browsers enforce the Same-Origin Policy (SOP), which prevents a script on one site from reading data from another site. This prevents evil.com from reading your emails on gmail.com.

CORS allows servers to relax this policy safely. When a web app makes a cross-origin request, the browser sends an Origin header. The server responds with Access-Control-Allow-Origin.

Common Misconfigurations

• Wildcard Origin (*): Allowing all origins. While okay for public APIs, it’s dangerous if combined with Access-Control-Allow-Credentials: true.
• Reflecting the Origin: Dynamically setting the allowed origin based on the Origin header without validation. This effectively bypasses the SOP entirely.

Best Practices

• Be Specific: Only allow the specific domains that need access.
• Avoid Credentials if Possible: If your API doesn’t need cookies or Authorization headers, don’t allow them.
• Use a Security Middleware: Use well-tested libraries to handle CORS configuration instead of manual header management.

Summary Comparison

Understanding these three pillars of web security is essential for building robust, modern applications. By implementing defense-in-depth strategies, you can protect both your server’s internal infrastructure and your users’ private data.

Stay secure, and happy coding!