We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design Masterclass · Security Architecture
Free preview: the first 2 parts of this 6-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Security Architecture
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
Your server sends HTML to the browser. But what if that HTML contains injected JavaScript from an XSS attack? What if the page is loaded inside an attacker's iframe to trick users into clicking hidden buttons (clickjacking)? What if the browser loads a resource over when your site is HTTPS?
Browsers are powerful. They execute JavaScript, load resources from any domain, embed pages in iframes, and guess content types. By default, all of these behaviors are permissive. Security headers are HTTP response headers that restrict this permissiveness. They tell the browser: "Only load scripts from these domains. Only connect over . Do not allow anyone to embed this page in an iframe."
Setting the right headers takes 10 minutes and provides protection against entire classes of attacks. Yet most applications ship without them. Scott Helme runs securityheaders.com, a free scanner that grades your headers from A+ to F. In 2023, only 6.2% of the top 1 million sites scored an A or above. The other 93.8% were missing headers that take minutes to add.
Twitter (now X) got an F until 2019 because they shipped without a Content-Security-Policy. GitHub has maintained an A+ since 2016 because they deploy CSP, HSTS, and X-Frame-Options on every response.
Four headers do most of the work. Each prevents a specific attack class, and each has different deployment complexity.
Content-Security-Policy (CSP) is the most powerful and the hardest to configure. It defines an allowlist of trusted content sources: only scripts from these domains, only styles from these domains, only images from these domains. If an XSS attack injects a script tag pointing to evil.com, the browser blocks it because evil.com is not on the allowlist. GitHub's CSP runs to over 500 characters because they allowlist specific CDNs, analytics providers, and their own subdomains.
Strict-Transport-Security (HSTS) is the highest impact per effort. A single header tells browsers to always use HTTPS for your domain, even if the user types http://. This prevents SSL stripping attacks where an attacker on the network downgrades the connection from HTTPS to . The preload directive submits your domain to browser preload lists (hardcoded in Chrome, Firefox, Safari) so the protection applies on the very first visit.
X-Frame-Options prevents clickjacking. Set to DENY and no other site can embed your page in an iframe. Set to SAMEORIGIN and only your own domain can frame itself. Simple, one-line, zero-risk for most applications.
CORS (Cross-Origin Resource Sharing) controls which domains can make JavaScript requests to your API. The browser enforces same-origin policy by default. CORS headers tell it which exceptions to allow. Never set Access-Control-Allow-Origin: * on authenticated endpoints, that opens your API to every website on the internet.