When you build a web application and deploy it on the internet, you’re exposed to various attacks. Hackers use different techniques to steal data, hijack sessions, or redirect users to malicious sites. While firewalls and HTTPS provide basic protection, security headers<\/strong> are an additional layer of defense that run at the browser level.<\/p>\n Think of security headers as instructions you send to every visitor’s browser, telling it: “Don’t trust scripts from unknown sources,” “Don’t display this page inside someone else’s website,” and “Always talk to me securely.” These are simple text messages included in every HTTP response, but they’re incredibly powerful.<\/p>\n Caddy<\/strong>, a modern web server, makes adding these headers effortless. Unlike older servers like Apache or Nginx where you need to manually write complex configurations, Caddy provides a clean, simple syntax for implementing security headers consistently across your entire application.<\/p>\n Before diving into the configuration, let’s understand the threats these headers defend against:<\/p>\n An attacker injects malicious JavaScript code into your web page. When users visit, the script runs in their browsers, stealing login cookies or sensitive information.<\/p>\n Example:<\/strong> A comment form that doesn’t validate input allows someone to post An attacker embeds your website inside a hidden frame on their own malicious site. Users think they’re clicking a button on your site, but they’re actually clicking something invisible on the attacker’s page.<\/p>\n Example:<\/strong> You see “Claim Your Prize!” on a site, but clicking it actually approves a bank transfer on your real bank’s website (which is hidden underneath).<\/p>\n Older browsers would guess the file type based on content, not just the filename. An attacker could upload a malicious script with a Example:<\/strong> Upload a file named An attacker intercepts your connection and reads or modifies data in transit. This happens when someone connects to unsecured HTTP instead of HTTPS.<\/p>\n Example:<\/strong> Using public WiFi at a caf\u00e9, an attacker intercepts your login credentials when you visit an HTTP website.<\/p>\n When you click a link to another site, that site can see which page you came from (the referrer). This can leak sensitive information.<\/p>\n Example:<\/strong> If you click a link from a private healthcare website to a search engine, that search engine knows you visited a healthcare site.<\/p>\n Websites might request access to your camera, microphone, or location without your explicit consent.<\/p>\n Example:<\/strong> A malicious website silently accesses your webcam to spy on you.<\/p>\n Here’s the complete Caddy configuration with detailed explanations:<\/p>\n
\nCommon Web Vulnerabilities Security Headers Protect Against<\/h2>\n
1. Cross-Site Scripting (XSS)<\/strong><\/h3>\n
<script>alert('hacked')<\/script><\/code>, which then runs for everyone who views that comment.<\/p>\n2. Clickjacking<\/strong><\/h3>\n
3. MIME Type Sniffing<\/strong><\/h3>\n
.jpg<\/code> extension, and the browser might execute it as JavaScript anyway.<\/p>\nphoto.jpg<\/code> containing JavaScript code. Some browsers might run it as a script instead of displaying it as an image.<\/p>\n4. Man-in-the-Middle (MITM) Attacks<\/strong><\/h3>\n
5. Information Leakage via Referrer<\/strong><\/h3>\n
6. Unauthorized Browser Feature Access<\/strong><\/h3>\n
\nUnderstanding the Security Headers Configuration<\/h2>\n
example.com<\/span> {\n header {\n Strict<\/span>-Transport<\/span>-Security<\/span> \"max-age=31536000; includeSubDomains; preload\"<\/span>\n X-Content<\/span>-Type<\/span>-Options<\/span> \"nosniff\"<\/span>\n X-Frame<\/span>-Options<\/span> \"DENY\"<\/span>\n X-XSS<\/span>-Protection<\/span> \"0\"<\/span>\n Referrer<\/span>-Policy<\/span> \"strict-origin-when-cross-origin\"<\/span>\n Permissions<\/span>-Policy<\/span> \"geolocation=(), microphone=(), camera=()\"<\/span>\n }\n\n reverse_proxy localhost<\/span>:3000<\/span>\n}\n<\/code><\/pre>\n