The Static Site Fortress

If you’ve been following my journey building anthonytristan.info, you know I run on Astro — the web framework that’s been quietly dominating the content-driven web. And one of the things that makes Astro genuinely different from the WordPress-and-pray approach is its security posture.

Here’s the thing most people don’t realize: static sites don’t have a backend to attack.

No database to SQL-inject. No server-side runtime processing user input on every request. No session management to hijack. No plugin ecosystem full of unpatched vulnerabilities. When someone hits your Astro site, they get pre-rendered HTML files served from a CDN. That’s it. There’s literally nothing to exploit on the server side because there is no server side.

Think about that for a second. Every dynamic site — WordPress, Next.js SSR, Django, Rails — has to deal with:

• SQL injection — not possible when there’s no database
• XSS via server-side rendering — not possible when pages are pre-built
• Session hijacking — not possible when there are no sessions
• Server-side request forgery — not possible when there’s no server processing requests
• Zero-day runtime exploits — not possible when there’s no runtime

Astro just… sidesteps the entire category of server-side vulnerabilities by not having a server. It’s the digital equivalent of “can’t get robbed if you don’t carry cash.”

Astro 6 and Content Security Policy: The Most Requested Feature

Now here’s where it gets REALLY interesting.

Astro 6 dropped earlier this month and it shipped with something huge: first-class Content Security Policy (CSP) support. This was literally Astro’s most upvoted feature request, and they delivered it in a way that no other JavaScript meta-framework has pulled off.

CSP is like a bouncer for your browser. It tells the browser exactly which scripts, styles, fonts, and resources are allowed to load — and blocks everything else. This is your primary defense against cross-site scripting (XSS) attacks, which are still one of the most common attack vectors on the web.

The problem? CSP is deceptively hard to implement. You need to know every script and style on every page so they can be hashed and included in the policy. For static pages, you can compute that at build time. For dynamic pages, content changes per request — meaning you need to hash on the fly and inject the right headers at runtime.

Astro 6 handles both. One flag in your config:

// astro.config.mjs
export default defineConfig({
  security: {
    csp: true
  }
});

That’s it. Astro automatically hashes all scripts and styles in your pages and generates the appropriate CSP headers. No manual hash management. No unsafe-inline hacks. It just works — for static AND server-rendered pages.

Want more control? The full configuration API lets you customize hashing algorithms, add directives for external scripts, and even configure CSP on a per-page basis using a runtime API. It even works with Astro’s responsive images out of the box — image styles get hashed and included in your policy automatically.

This is the kind of “secure by default” approach that makes me genuinely excited about web development in 2026.

The Cloudflare Acquisition: Security Gets a Turbo Boost

Oh, and did I mention? Cloudflare acquired Astro in January 2026.

Let that sink in. The company that runs one of the largest security and CDN networks on the planet now owns the framework. Astro remains open-source and MIT-licensed, but now it’s got Cloudflare’s entire infrastructure team behind it.

What does this mean for security?

• Astro’s dev server now runs on workerd — Cloudflare’s open-source Workers runtime — so your local development environment matches production exactly. No more “works on my machine” surprises.
• Cloudflare’s edge network provides DDoS protection, bot management, and WAF rules at the infrastructure level before traffic even reaches your site.
• Cloudflare Turnstile integration replaces those annoying CAPTCHAs with invisible, privacy-first bot detection for any forms or API endpoints you expose.
• Post-quantum cryptography — Cloudflare is already rolling out PQC capabilities, and Astro sites on their platform benefit from that automatically.

The combination of Astro’s static-first, zero-JavaScript-by-default architecture with Cloudflare’s global security infrastructure is genuinely hard to beat.

Why My AI Got Blocked (And Why That’s Beautiful)

So back to my story. Why couldn’t Comet read my blog?

It comes down to the layers working together:

1. robots.txt — Astro makes it trivial to generate restrictive bot directives. Whether through the @astrojs/sitemap integration or a static file in your public/ directory, you control exactly which crawlers can access what.

2. Hosting layer protections — If you’re behind Cloudflare (which, post-acquisition, is increasingly the default path for Astro sites), their bot management kicks in before anything else. Known AI scrapers, aggressive crawlers, and suspicious traffic patterns get filtered at the edge.

3. No attack surface to probe — Even if a bot DOES get through, what are they going to do? There’s no database to dump, no admin panel to brute-force, no API keys sitting in a server-side environment variable that could leak through an error page. The “worst case” is they read your public HTML — which is the whole point of a website anyway.

The beautiful irony is that the security is so seamless, so layered, that it caught my own tool in the crossfire. And honestly? I wouldn’t have it any other way. If my site is blocking sophisticated AI agents from scraping content, imagine what it’s doing to actual bad actors.

Security in Action: Analytics Spike

On March 26th, I noticed a sudden spike in traffic to my site, with a significant portion coming from the Russian Federation. The analytics below show both the country breakdown and the request spike during that period:

This kind of traffic pattern often indicates automated bots or scanners looking for vulnerabilities. Thanks to Astro’s static-first architecture (no backend, no database, no exposed server logic) and strong security practices, there was nothing for them to exploit. At worst, bots could scrape public HTML, but the real attack surface was essentially zero.

It’s a real-world example of why building with Astro and following modern security best practices pays off. Even during a targeted traffic spike, the site remained secure and unaffected.

The Takeaway

If you’re still running a WordPress site with 47 plugins, a MySQL database exposed to the internet, and a prayer… maybe it’s time to reconsider.

Astro gives you:

• Zero server-side attack surface by default
• Built-in CSP that automatically hashes and secures every script and style
• Cloudflare’s global security infrastructure as a natural deployment target
• Static output that’s inherently resilient to the vast majority of web attacks
• 100/100 Lighthouse scores because performance and security go hand in hand

And if you’re a developer who cares about protecting your intellectual property — your blog posts, your research, your original content — Astro’s architecture combined with proper robots.txt configuration and Cloudflare’s bot management gives you real control over who and what accesses your work.

My AI assistant learned that lesson firsthand today. And honestly, I think that’s pretty cool.

Building something on Astro? I’d love to hear about your setup. Find me at anthonytristan.info — if you can get past the security. 😏