Check your security headers in seconds

SiteCurl checks 10 security settings that guard your site: Content Security Policy (CSP), X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, Cross-Origin-Opener-Policy (COOP), HTTPS enforcement, HSTS, SSL certificate status, and mixed content.

Each setting tells browsers how to handle your site's resources. Missing settings let browsers fall back to weak defaults that leave gaps for attackers. The check shows which protections you have, which ones you lack, and what value to set.

These are HTTP response headers. They are sent by your server with every page load. Visitors never see them, but their browsers read and enforce them automatically.

Your server sends these headers to the browser before the page loads. They say things like 'do not let other sites frame this page' and 'only run scripts from these sources.' Without them, browsers use weak defaults.

The top attack headers stop is script injection (XSS). A bad actor slips a script into your page through a form field or URL. Without CSP, the browser runs it. It can steal cookies, move users to a fake page, or change what the page shows. CSP tells the browser which scripts are OK.

The second is clickjacking. A bad actor loads your site in a hidden frame on their page. A visitor thinks they click a button on the fake page, but they really click one on yours. This can start a purchase or change a setting. X-Frame-Options stops your site from being framed.

These are real attacks, not rare ones. They show up in breach reports every week. The fix is a few lines of server setup. Yet most sites ship with none of these headers because the defaults seem to work.

These headers stop common attacks. Without CSP, bad actors can inject scripts that steal user data. Without X-Frame-Options, they can put your site in a fake page and trick users. Without X-Content-Type-Options, browsers may run a file as code even if your server said it was plain text.

Adding headers is one of the fastest safety wins. Most take one line in your server config. You do not need to change your app code. Once set, they guard every page on your site with every page load.

Headers also show up in scans run by clients or buyers. If they scan your site and see missing headers, it raises red flags. Clean headers pass that first check.

SaaS products that store user data need these the most. If your app has login pages or payment flows, missing headers are a real risk. Big buyers often scan your site before they sign up. Missing headers are the first thing they flag.

Online stores need headers to guard checkout flows. Even if Stripe or PayPal handles the payment, a script attack on your product page could send buyers to a fake checkout form.

Agency sites are lower risk but still gain from clean headers. A strong header report shows skill to would-be clients. It also guards contact forms and any client login areas from basic attacks.

Step 1: Add X-Content-Type-Options. Set it to nosniff. This header never breaks anything. It tells browsers to trust the file type your server says, not guess.

Step 2: Add X-Frame-Options. Set it to DENY if your site should never be in a frame, or SAMEORIGIN if you frame your own pages. This stops clickjacking attacks.

Step 3: Add Referrer-Policy. Set it to strict-origin-when-cross-origin. It sends your domain to other sites but hides the full URL path. This keeps user data private without breaking your analytics.

Step 4: Add Permissions-Policy. Turn off features you do not use: camera=(), microphone=(), geolocation=(). This stops third-party scripts from using device features on your pages.

Step 5: Add CSP (with care). Start with Content-Security-Policy-Report-Only to watch without blocking. Check the browser console for what gets flagged. Once you know what your site loads, switch to enforcing mode.

Where to add them: In Nginx, use add_header in your server block. In Apache, use Header set in .htaccess. In Cloudflare, use Transform Rules. In Render, Netlify, or Vercel, use the header setup file.

Turning on CSP without testing first. A strict CSP blocks all scripts not on your list. If you left out Google Analytics, tracking breaks. If you left out an inline script, the page may not load right. Always start with report-only mode.

Using 'unsafe-inline' in CSP. This lets any inline script run, which is the exact thing XSS attacks use. It undoes most of what CSP is meant to do. Use nonces or hashes instead.

Using ALLOW-FROM in X-Frame-Options. Chrome and Safari do not support it. Use CSP's frame-ancestors rule instead. It works in all modern browsers.

Missing headers on error pages. Your 404 and 500 pages need the same headers as normal pages. If Nginx or Apache serves static error files, those files may need their own header rules.

After adding headers, check them by running curl -sI https://yoursite.com and looking for the header names in the output. Each header you added should show up.

Run another SiteCurl scan to see if the finding count drops. For CSP, open your browser console (F12) and look for policy warnings. If scripts get blocked that should be allowed, adjust your list before switching from report-only to enforcing mode.

Test more than one page. Some server setups only add headers to certain routes. Check your home page, a blog post, and an error page to make sure headers are the same across your site.

Headers are the fastest safety win. They take minutes to add and guard every page at once. Most hosts let you set them without code changes. Start with X-Content-Type-Options and X-Frame-Options (they never break things), then add CSP in report-only mode. Once you know what loads, switch CSP to enforcing mode.