Web Security Foundations

Build the mental model

The browser enforces the same-origin policy - an origin is scheme + host + port, and this boundary is the foundation CORS builds on.

CORS is the mechanism that lets a server permit cross-origin requests. CORS is not authentication and not authorization - it only governs browser access.

XSS, defensively: never let untrusted input become executable code; rely on framework output escaping and a Content-Security-Policy.

CSRF, defensively: since browsers may attach cookies automatically, SameSite, CSRF tokens, and origin checks defend against it.

HTTPS
Authentication
Authorization (per-action)
Input validation / output safety
Secure cookies / server-side secrets
CORS configuration
Dependency hygiene / monitoring

text

WEB SECURITY: LAYERS THAT WORK TOGETHER
---------------------------------------
WEB SECURITY: LAYERS THAT WORK TOGETHER
------------------------------------------

  +---------------------------------------+
  |   HTTPS (encrypts the transport)       |
  +---------------------------------------+
  |   Authentication (who are you)         |
  +---------------------------------------+
  |   Authorization (what can you do)      |
  +---------------------------------------+
  |   Input Validation / Output Safety     |
  +---------------------------------------+
  |   Secure Cookies / Server-Side Secrets |
  +---------------------------------------+
  |   CORS Configuration                   |
  +---------------------------------------+
  |   Dependency Hygiene / Monitoring      |
  +---------------------------------------+

  Removing any one layer weakens the whole stack.

Connect it to a real scenario

A server keeps a trusted origin allow-list and compares each request's origin against it before deciding allow or deny.

Treat this as a starting mental model, not production CORS - real CORS involves preflight requests, credentials, and multiple headers.

Same-origin (scheme + host + port) is the browser's basic security boundary, and CORS is how a server explicitly relaxes it.
CORS controls whether a cross-origin request is allowed - it is not authentication and not authorization.
Web security is a stack of layers - HTTPS, auth, authorization, input/output safety, secrets, CORS, and monitoring - not any single fix.

Web Security Foundations Checklist

HTTPS used across the whole site
Authentication implemented correctly
Authorization enforced per-action, not just per-login
User input validated
Output properly escaped
Cookies marked Secure/HttpOnly where appropriate
Secrets kept server-side
CORS configured deliberately (not wide-open)

Try the working example

javascript

function checkCors(requestOrigin, allowedOrigins) {
  const allowed = allowedOrigins.includes(requestOrigin);
  return {
    origin: requestOrigin,
    decision: allowed ? "allow" : "deny",
  };
}

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

console.log(checkCors("https://app.example.com", allowedOrigins));
console.log(checkCors("https://evil-site.com", allowedOrigins));

You should see

Logs { origin: 'https://app.example.com', decision: 'allow' } and { origin: 'https://evil-site.com', decision: 'deny' }.

5-minute try-it

Add your own site's origin to the allowedOrigins list in the code and confirm checkCors returns 'allow' for it.

One important caution

Assuming CORS being configured means requests are authenticated or authorized - it only governs cross-origin browser access.

Leaving CORS wide open (allowing any origin) instead of maintaining a deliberate, specific allow-list.

OWASP - Top Ten Web Application Security Risks — How the Web Works