---
title: "22 — Web Security — Defending the Browser's 'Run Anyone's Code' Model"
uid: web-security
tags: ["security", "https", "cors", "owasp", "roadmap:frontend", "csp", "xss"]
excerpt: "The browser trusts the origin — and every defense either enforces that boundary, encrypts the pipe, declares trusted sources, or names the known attacks."
date: 2026-08-12T18:35:08+0000
source: https://www.aveshina.my.id/en/blog/web-security
---
CORS, CSP, TLS, OWASP, XSS, CSRF — a wall of acronyms that all somehow meant "bad thing, fix it." Writing them down collapsed the wall into one idea I could actually hold.
The model that clicked: **the browser's foundational decision is to run anyone's code and fetch anyone's resources, and it decides what to trust by *origin*.** Every web security defense I've met is a response to that one decision. Each one either **enforces the origin boundary** (CORS), **encrypts the pipe** between origins (HTTPS/TLS), **declares which sources are trusted to execute** (CSP), or **enumerates the known attacks** so you know what you're defending against (OWASP Top 10). Four jobs, one model. Once I saw it that way, the acronyms stopped being a list and started being a layered defense.
```figure
```
## The premise worth stating plainly
A web page is unusual software. A native app is a binary I chose to install and the OS largely trusts; a web page is HTML, CSS, and JavaScript that **the browser fetches and executes on every visit, from servers it didn't vet** [1]. The browser can't refuse to run it — that's the whole point of the web. So instead it asks one question on which everything hangs: *where did this come from?* That "where" is the **origin** — the combination of scheme, host, and port (https://aveshina.my.id:443). Same origin is implicitly trusted; different origin is not. Every defense below is a refinement of that single rule.
## CORS — enforcing the origin boundary
The browser's default rule is the **same-origin policy**: a script running on aveshina.my.id may not read responses from requests it makes to api.twitter.com [2]. That sounds restrictive, and it is —deliberately. Without it, any site I visited could silently call my bank's API using my cookies and read the response.
CORS (Cross-Origin Resource Sharing) is the **relaxation mechanism**, not the restriction. It's how a server at api.example.com can say to a browser, "responses from me are allowed to be read by scripts at app.example.com" [2][3]. It works entirely through HTTP headers. For simple requests the server returns:
```
Access-Control-Allow-Origin: https://app.example.com
```
For requests that could change data (anything with a custom header, or methods like PUT/DELETE, or non-simple content types), the browser sends a **preflight** — an OPTIONS request asking "is this allowed?" — before the real request [3]. The thing I had to straighten out: **CORS is enforced by the browser, not the server.** The server is just declaring policy via headers; the browser is the one that blocks the response from reaching the script if the headers don't permit it. The same API called from curl has no CORS gate at all — because curl doesn't implement the same-origin policy.
CORS also mitigates **CSRF** (Cross-Site Request Forgery) in practice: because cross-origin requests are gated, a malicious site can't trivially fire authenticated state-changing requests at my API and have them succeed — though CSRF ultimately needs its own defenses too (anti-CSRF tokens — one-time values a form must echo back — and SameSite cookies, which tell the browser not to send the cookie on cross-site requests), since simple form POSTs predate CORS and are allowed by default.
## HTTPS — encrypting the pipe
Same-origin policy assumes I can actually tell who I'm talking to and that the bytes aren't being tampered with in flight. On plain HTTP that assumption is false — anyone between the browser and the server (the coffee-shop Wi-Fi, an ISP, a compromised router) can read and alter the traffic.
HTTPS is the same HTTP conversation from my earlier notes, wrapped in **TLS** — an encryption layer that gives two guarantees [4][5]:
- **Confidentiality** — the bytes on the wire are encrypted; the man in the middle sees scrambled data (ciphertext).
- **Integrity** — TLS authenticates the server (via its certificate) and detects any tampering with the data.
The browser's padlock icon means exactly: *this conversation is encrypted and the server proved who it is.* It does **not** mean "this site is safe" or "this site is honest" — a phishing site can have a valid certificate and a padlock too. The certificate proves identity, not intent [4]. The single practical move this left me with: never send anything I'd mind an attacker reading over plain HTTP, and treat a site that loads mixed HTTP subresources on an HTTPS page as broken — the browser will block or warn.
## CSP — declaring trusted sources
CORS gates *cross-origin reads*. CSP (Content Security Policy) gates *what's allowed to execute at all*, even from the same origin. It's a defense against **XSS** (Cross-Site Scripting) — the attack where untrusted input ends up executed as JavaScript on my page because I didn't escape it [6][7].
CSP is a declarative allowlist, sent as a header (or tag), that names the trustworthy sources for each resource type. A strict policy looks like:
```
Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self'; img-src 'self' data:;
```
default-src 'self' is the spine: unless a more specific directive says otherwise, every resource — scripts, styles, images, fonts, frames — may only come from the page's own origin [7]. No inline scripts, no eval (a function that runs a string as code), no third-party CDNs (content delivery networks) I didn't explicitly allow. The payoff is that even if an attacker does slip into my HTML, the browser refuses to execute it, because inline scripts aren't in the allowlist. CSP turns XSS from "one missed escape and you're owned" into "one missed escape that the browser quietly refuses to run."
It also mitigates **clickjacking** (an attacker embedding my site in a hidden