Home » Programming » Web Security
📍 Unpin 🔗 Copy Link 📋 Copy Markdown ⬇️ Download
4 min read

Web Security: CORS and CSP

Web security involves protecting web applications from threats. Two fundamental browser-based security mechanisms are CORS (Cross-Origin Resource Sharing) and CSP (Content Security Policy).

1. CORS (Cross-Origin Resource Sharing)

CORS is a mechanism that allows a server to indicate any origins (domain, scheme, or port) other than its own from which a browser should permit loading resources.

The Same-Origin Policy (SOP)

By default, browsers enforce the Same-Origin Policy. This prevents a malicious script on one page (e.g., evil.com) from obtaining access to sensitive data on another web page (e.g., bank.com).

  • Origin: Defined by Protocol + Host + Port (e.g., https://example.com:443).

How CORS Works

If your frontend (client.com) tries to fetch data from your backend (api.com), the browser blocks it by default because the origins differ. To allow this, the backend must send specific HTTP headers.

  • Access-Control-Allow-Origin: Specifies which origins are allowed.
    • Access-Control-Allow-Origin: https://client.com (Secure)
    • Access-Control-Allow-Origin: * (Insecure, allows everyone)
  • Access-Control-Allow-Methods: Allowed HTTP methods (GET, POST, PUT).
  • Access-Control-Allow-Headers: Allowed custom headers.

Preflight Requests

For "complex" requests (e.g., requests with custom headers or methods like PUT/DELETE), the browser first sends an OPTIONS request to check permissions. This is called a Preflight Request.

2. CSP (Content Security Policy)

Content Security Policy (CSP) is an added layer of security that helps to detect and mitigate certain types of attacks, including Cross-Site Scripting (XSS) and data injection attacks.

The Goal: Prevent XSS

XSS attacks occur when an attacker injects malicious scripts into content that is viewed by other users. CSP allows you to tell the browser: "Only execute scripts that come from these trusted domains."

How it Works

You configure CSP by sending the Content-Security-Policy HTTP header from your server.

Content-Security-Policy: default-src 'self'; script-src 'self' https://apis.google.com

Common Directives

  • default-src: The fallback for other directives.
  • script-src: Defines valid sources for JavaScript.
  • style-src: Defines valid sources for stylesheets.
  • img-src: Defines valid sources for images.
  • connect-src: Restricts the URLs which can be loaded using script interfaces (fetch, XHR, WebSockets).

Example Policy

Content-Security-Policy: default-src 'self'; img-src *; script-src userscripts.example.com
  • Images can load from anywhere (*).
  • Scripts can only load from userscripts.example.com.
  • Everything else can only load from the same origin ('self').

3. CSRF (Cross-Site Request Forgery)

CSRF is an attack that forces an end user to execute unwanted actions on a web application in which they are currently authenticated.

The Mechanism

It relies on the fact that browsers automatically send cookies (including session IDs) with every request to a domain, even if that request originated from a different site.

  • Example: You are logged into your bank. You visit a malicious site that has a hidden form or image tag: <img src="http://bank.com/transfer?to=attacker&amount=1000">. Your browser sends the request to bank.com with your session cookies, and the bank processes the transfer.

Prevention

  1. Anti-CSRF Tokens: The server generates a unique, unpredictable token that the client must include in the request (usually in a hidden form field or header). Since the attacker can't read data from the bank's site (due to SOP), they can't guess this token.
  2. SameSite Cookies: Setting the SameSite attribute on cookies helps.
    • SameSite=Strict: Cookies are never sent on cross-site requests.
    • SameSite=Lax: Cookies are not sent on cross-site subrequests (like images or frames), but are sent when a user navigates to the origin site (i.e., follows a link).

4. XSS (Cross-Site Scripting)

Cross-Site Scripting (XSS) is a vulnerability that allows an attacker to inject malicious scripts into web pages viewed by other users.

Types of XSS

  1. Reflected XSS (Non-Persistent): The malicious script is reflected off the web server, such as in an error message or search result. The attack is delivered via a link.

    • Example: A user clicks http://example.com/search?q=<script>alert(1)</script>. The server echoes the query back in the HTML: You searched for: <script>alert(1)</script>.

  2. Stored XSS (Persistent): The malicious script is permanently stored on the target server (e.g., in a database, forum post, comment field). The victim retrieves the malicious script when they view the stored content.

    • Example: An attacker posts a comment: Great post! <script>stealCookies()</script>. Every user who views the comments executes the script.

  3. DOM-based XSS: The vulnerability exists in the client-side code rather than the server-side code. The attack payload is executed as a result of modifying the DOM "environment" in the victim's browser used by the original client-side script.

    • Example: A script reads window.location.hash and writes it to the page using innerHTML without sanitization.

programming/cybersecurity-basics programming/rest-apis programming/client-vs-backend

Backlinks

Created: March 17, 2026 • Last Modified: January 31, 2026