Static vs Dynamic Websites: Which Is Safer?

As of 23 October 2026, PHP2Shell has been fixed in the PHP engine, and owners of dynamic PHP sites have spent the week updating PHP and restarting servers. A purely static site, made of prebuilt files served from a content delivery network, had no PHP on its public server to patch. So static is safer in one specific way: it runs far less code where attackers can reach it.

That doesn't make static automatically safe, or dynamic automatically risky. Most business sites need something that runs on a server: a contact form, site search, a booking tool, a checkout or a place for staff to edit content. Each of those brings back server code that someone has to patch. And a headless site, with a static frontend and a CMS backend, still runs that backend somewhere.

This guide explains the difference in plain terms, what PHP2Shell showed about each approach, what still needs a server on a "static" site, how headless fits in between, and who should choose which.

Static, Dynamic and In Between: Plain Definitions

• Static site. Every page is built ahead of time into ordinary files (HTML, CSS, JavaScript, images) and served as is. Visiting a page reads a file; no program on the server builds the page for you.
• Dynamic site. Pages are built on the server each time someone visits, usually from a database. WordPress, Drupal, Joomla and Magento work this way in their standard setup, and the code that builds the page runs on PHP.
• Headless or hybrid site. The content lives in a CMS (the "backend"), and a separate frontend displays it. The frontend may be fully static, rendered on a server, or a mix. Our comparison of headless and traditional CMSs covers the business side.

Attack surface is the term security people use for everything on a site that an attacker can reach and send input to. The basic security difference between static and dynamic is the size of that surface.

Why Static Sites Expose Less

When a page is a prebuilt file, there is no login form on the page to guess, no database query to manipulate and no runtime processing each request. OWASP's attack surface cheat sheet recommends exactly this kind of reduction: "turning off features and interfaces that aren't being used" and "not storing confidential data that you don't absolutely have to."

Static hosting vendors make the case strongly, and their claims should be read as vendor claims:

• Jamstack.org, a site run by Netlify, says static architecture means "fewer servers and systems to harden against attack" and "read-only hosting reducing attack vectors even further."
• Netlify's security page says "content deployed to the edge nodes is fully prerendered and static, offering no active processes or surface area for attack." That is accurate for prebuilt files on its edge network. The same page lists "Application architecture," "Data handling" and "Authentication mechanisms" as customer responsibilities.

Both points hold at once. The static files are a very small target. Everything you add around them, such as functions, forms, a build pipeline, third-party scripts and team accounts, is still surface you own.

What PHP2Shell Showed About Each Approach

PHP2Shell is two critical flaws in the PHP engine that can allow unauthenticated remote code execution. On a dynamic PHP site, the flaw sat on every page request, because every request reached PHP. The fix was the same for every PHP site regardless of CMS: install a patched PHP build and restart every PHP worker. Updating WordPress, Drupal or a plugin didn't help. Our PHP2Shell guide for WordPress shows that process for the most common case.

A static site with no PHP anywhere had nothing to patch. But three patterns showed where "static" stops protecting you:

1. A PHP backend behind a static frontend. A headless WordPress or Drupal site still runs PHP for its CMS. That server needed the fix like any other.
2. PHP behind a protective network. Vercel's PHP2Shell bulletin says its firewall rules covered "PHP functions deployed on Vercel" and "Requests Vercel rewrites or proxies to external PHP backends," but that "Requests that bypass Vercel's network, including direct requests to an external PHP backend, are not covered." It told customers to "Upgrade the PHP runtime to a patched release immediately, regardless of WAF protections or hosting provider."
3. Custom PHP beside a hosted platform. BigCommerce said it patched its own services, then told merchants: "If you run your own PHP applications, please review any custom PHP solutions... and apply the PHP patches as soon as possible."

So the PHP2Shell question for a static or headless site is simple: does any part of it, including the CMS, a form handler or an integration, run on PHP? If yes, that part needed patching.

What Still Needs a Server on a "Static" Site

Most business sites need at least one of these. Each brings server code back, whether you run it or a vendor does.

Hosting platforms reflect this. Cloudflare's Pages documentation describes "Pages Functions" that "deploy server-side code to enable dynamic functionality," and now tells new projects to start with Workers, its broader application platform. Vercel's shared responsibility page says PCI customers "are responsible for choosing an appropriate payment gateway provider to integrate an iframe." If you take card payments, our guide to PCI DSS 4.0 website requirements covers the script rules that apply on any architecture.

Server-rendered JavaScript has its own engine-level risk. In December 2025, React disclosed React2Shell (CVE-2025-55182), "an unauthenticated remote code execution vulnerability in React Server Components" rated CVSS 10.0. CISA added it to its Known Exploited Vulnerabilities catalog on 5 December 2025. Vercel's advice then matched its PHP2Shell advice: "do not rely on the WAF for full protection. Immediate upgrades to a patched version are required."

Static, Dynamic and Headless Side by Side

Headless as the Middle Path

Headless lets editors keep a familiar CMS while visitors get a static or mostly static frontend. It can shrink what the public sees. It doesn't remove the backend, and it adds an API between the two halves. Our headless and custom website security guide covers the frontend side in detail: dependencies, secrets and API routes. On the CMS side, using WordPress as the example, the official documentation sets a few limits worth knowing:

• Don't switch off the REST API. The REST API is how a headless frontend reads WordPress content. The REST API FAQ says "You should not disable the REST API; doing so will break WordPress Admin functionality."
• Require authentication if content isn't public. The same FAQ says "You can require authentication for all REST API requests by adding an is_user_logged_in check to the rest_authentication_errors filter." A developer should make that change.
• Use the right credentials for the frontend. WordPress has shipped Application Passwords since version 5.6, and the authentication docs say they are sent "over https:// using Basic Auth."
• Patch the backend as a real server. A CMS backend that only editors use is still a PHP server, and PHP2Shell didn't require a login.

Hosted headless CMS products shift backend patching to the vendor, the same way hosted website builders do. Self-hosting a headless WordPress or Drupal backend keeps it with you or your host. If you are weighing a headless build, our headless CMS development team plans both halves together.

Who Should Choose Which

Static and headless builds trade an admin panel and a runtime for a build pipeline and a dependency tree. That is a better trade only if someone will watch those too. Our guide to the most secure way to build a website compares languages and stacks on the same terms.

Switching Is Not This Week's Fix

If your site runs on PHP, the PHP2Shell fix is a patched PHP build and a restart, and it takes far less time than a rebuild. Moving to static or headless can be a sound decision for the next version of your site, but it should come after the patch, with a plan for content editing, forms, redirects and search rankings. Our secure website rebuild planning guide covers how to scope that work.

Conclusion

As of 23 October 2026, static sites are safer in one clear way: prebuilt pages run no application code on the public server, so engine flaws like PHP2Shell have nothing to hit there. But forms, search, logins, checkout and any CMS backend bring server code back, and a headless backend still needed the PHP2Shell fix like any PHP server. Choose the architecture whose remaining server parts you can name an owner for. If a PHP server sits anywhere in your setup and you're not sure it was patched and restarted, our emergency PHP patching team can check it with you. Every PHP2Shell guide is in our PHP2Shell Resource Center.

Frequently Asked Questions