The 4 Website Security Basics Almost Everyone Skips

Quick answer: across real sites scanned in this series, one lovable app, one bolt.new app, dozens of others, four specific gaps keep showing up again and again: no DMARC record, no Content-Security-Policy header, no Strict-Transport-Security header, and no clickjacking protection. None of them stop a site from working. All four are DNS records or response headers, fixable in an afternoon, and all four sit quietly unfixed on most sites built fast, because nothing in a normal build-and-launch process ever forces the question.

This isn't a ranking of the worst security problems a site can have. It's the specific handful that shows up so often it stops looking like bad luck and starts looking like a pattern.

Why these four, specifically

Every one of them shares the same shape: invisible from inside the product, and free to skip because skipping them changes nothing about whether the app works. A missing DMARC record doesn't break email. A missing CSP header doesn't break a page render. Nobody clicking through a demo, testing a checkout flow, or showing a friend a new build is ever going to stumble onto any of these by accident. They only show up when something outside the team, a scanner, a bot, or someone with worse intentions, goes looking on purpose.

That's also exactly why they're cheap to fix once found. None of the four touch application logic. They're configuration: a DNS record here, a response header there.

1. DMARC: stopping people from spoofing your email

Without a DMARC record, there's nothing telling mail servers what to do when they see an email claiming to be from your domain but not actually sent by your systems. In practice, that means anyone can send an email that appears to come from your company, no compromise of your systems required, just a spoofed "From" address and a mail server that has no policy telling it to reject that.

The fix is a single DNS TXT record. A basic monitoring policy looks something like:

v=DMARC1; p=none; rua=mailto:[email protected]

Once you've watched the reports for a while and confirmed your own legitimate mail is passing, tighten p=none to p=quarantine or p=reject so spoofed mail actually gets blocked instead of just reported.

2. Content-Security-Policy: the fence around injected scripts

A Content-Security-Policy header tells the browser which sources are allowed to run scripts, load styles, or fetch content on your page. Without one, if a malicious script ever ends up on the page, through a compromised third-party widget, a stored XSS bug, anything, it runs with no restriction at all.

A CSP doesn't prevent every way a script could get injected in the first place, that's a separate problem. What it does is limit the blast radius if one does. A reasonable starting policy is stricter than nothing but not so strict it breaks the site:

Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'

From there, add specific allowances for the third-party scripts and fonts the site actually needs, rather than starting wide open.

3. Strict-Transport-Security: making HTTPS non-optional

Even a site that redirects HTTP to HTTPS can have a gap: a visitor's very first request, before the redirect happens, can be intercepted and quietly downgraded to plain HTTP. Without an HSTS header telling the browser "always use HTTPS for this domain, don't even try plain HTTP," that window stays open every single time.

Strict-Transport-Security: max-age=31536000; includeSubDomains

The max-age value is how long the browser remembers to enforce HTTPS-only for the domain, a year is a common default. includeSubDomains extends the same rule to every subdomain, worth adding unless you specifically need an HTTP-only subdomain for something.

4. Clickjacking protection: stopping your site from being framed

Without clickjacking protection, another site can load your page invisibly inside an iframe and layer its own content on top, tricking a visitor into clicking something on your site while believing they're clicking something else entirely. It's a real technique with a real name, not a theoretical risk.

Two headers cover this, and using both is standard practice since browser support differs slightly:

X-Frame-Options: DENY
Content-Security-Policy: frame-ancestors 'none'

If the site legitimately needs to be embedded somewhere, replace DENY/'none' with the specific origin that's allowed to frame it, rather than leaving the door open to everyone.

Where these actually get configured

None of the four live in application code. That's the whole point: they're set at the platform or DNS level, not in a codebase.

• DMARC is added in your DNS provider's dashboard as a TXT record, the same place you'd manage any other DNS entry.
• CSP, HSTS, and clickjacking headers are usually set either in your hosting platform's configuration (many platforms have a dedicated headers config file or dashboard setting) or in a reverse proxy/CDN layer sitting in front of the app.
• If you're on a platform that doesn't expose header configuration directly, a CDN or edge function in front of the site is the usual workaround, adding the headers there instead of at the origin.

What this costs you if you skip it

None of these four failures show up as a bug report. They show up as a spoofed email your customer receives with your company name on it, a script that runs unrestricted because nothing was there to stop it, a downgraded connection nobody noticed until it mattered, or a support ticket about "something weird" that traces back to a page loaded inside someone else's frame. By the time any of that happens, the fix is the same afternoon of DNS and headers it always was, just attached to a worse story.

Final Thoughts

None of this requires a security background to understand or fix. Four DNS records and headers, none touching how the site actually works, all closing a gap that's invisible until someone checks for it on purpose. The honest reason most sites are missing all four isn't neglect, it's that nothing in a normal build process ever asks the question. Checking is the only step that's actually required.