In short: A static website consists of finished HTML, CSS and image files that the web server merely serves. Because no PHP and no database run on the server, vulnerabilities such as PHP2Shell, SQL injection or planted web shells largely cease to be a risk. Other things count for the security of a static website instead: protected access to hosting, domain and build tools, maintained dependencies and carefully chosen third-party services. It suits above all websites that rarely change and need no customer accounts.
Why the question is being asked right now
PHP2Shell showed many companies how much hangs on a single component. A company website with ten pages, updated once a quarter, ran on the same PHP as a large online shop and was thus exposed to the same critical vulnerability. According to media reports, even authorities and municipalities took websites offline as a precaution.
The question is obvious: do we need PHP on the server for our website at all? For many small and medium-sized businesses the honest answer is: for delivery, often not. PHP regenerates the page on every request, although the content has not changed for weeks. How this works technically is described in How PHP generates a web page. What the vulnerability itself means is explained in What is PHP2Shell?.
How a static website works
With a static website, the page is not generated at the time of the visit but beforehand. A static site generator, such as Hugo, Jekyll or Eleventy, takes texts, images and templates and builds finished files from them. These files are uploaded to a simple web server or a content delivery network, that is, a distributed delivery network.
For editors, an editing tool can sit in front that accepts changes and triggers the rebuild. In some cases a so-called headless CMS is used for this, which only manages content and itself need not be publicly reachable. The visitor sees none of this; they receive only the finished files.
Static website and security compared
| Criterion | Dynamic PHP CMS | Static website |
|---|---|---|
| Program logic on the public server | Yes, on every request | No |
| Risk from vulnerabilities in the PHP interpreter | Yes, as with PHP2Shell | Does not apply on the delivery server |
| Database publicly connected | Yes | No |
| Typical entry points | Plugins, admin login, uploads, server | Access to hosting, domain, build system, third-party services |
| Forms, search, customer account | Built in | Only via external services or separate functions |
| Maintenance effort for editors | Low, familiar interface | Depends on the editing tool |
| Maintenance | Regular updates of CMS, plugins and PHP | Updates of build tools and dependencies |
| Suitability | Shops, portals, many editors, frequent changes | Company websites, landing pages, documentation |
The table shows: the attack surface shifts, it does not disappear. Instead of a publicly reachable PHP server, you have to protect the account at the host, the domain, the build pipeline and, where applicable, the editing tool.
Which risks remain with static websites
First, access. Anyone who takes over the hosting account, the domain access or the code repository can alter the website, entirely without PHP. Two-factor login and personal accounts are therefore mandatory.
Second, dependencies. Generators and templates often bring many packages with them, for example from npm. These must be kept up to date, because a compromised dependency can write malicious code into the finished files during the build. How to organise this is described in Keeping dependencies up to date.
Third, third-party services. Form services, search functions, analytics tools and embedded scripts run in visitors’ browsers or on foreign servers. Each of these services is a relationship of trust, including from a data protection perspective.
Fourth, the browser side. Even a static page should set security headers, such as a content security policy that defines which scripts may be loaded. The basics are in Security headers for websites.
Before switching, check which functions your website really uses. Often it is fewer than thought: pages, images, a contact form. Then the road to a static website is shorter than it first appears.
For whom switching is worthwhile, and for whom not
A static website is well suited for company pages of manageable size, landing pages for campaigns, product documentation and careers pages. Switching is especially worthwhile if the current website runs on an old PHP version and an upgrade would be due anyway.
It is less suitable for online shops, customer portals, booking systems and websites with many editors who publish daily. A dynamic system remains sensible there. A hybrid can help: the shop stays dynamic and is well hardened, while guides and company pages are served statically.
An often underestimated advantage shows in an emergency. Because the finished files can be rebuilt from templates and content at any time, a tampered website can quickly be reset to a known, clean state. The prerequisite is that content and templates are in a protected repository, changes are logged traceably and nobody edits the files directly on the server.
You do not necessarily need a security provider for the switch; an agency or developer can do it. If the previous website was compromised, however, content should be checked before it is taken over. Switch the CMS after a hack? covers this.
How does PHP SOS help?
- We check which functions your website actually needs and tell you openly whether a static solution is suitable.
- In a switch, we secure access to hosting, domain and build system with two-factor login and personal accounts.
- We check third-party services and set security headers so that the new website is also well protected in the browser.
- For PHP systems that remain, we take over updates and monitoring in the security maintenance contract.
Conclusion
A static website is not a cure-all, but for many company pages it is the simplest way to get rid of a whole class of risks. Where no PHP runs, PHP2Shell can do nothing. The security gained only holds, however, if access, dependencies and third-party services are taken as seriously as the server used to be.
Frequently asked questions
Can a static website still be hacked?
Yes. Server-side program logic falls away, and with it a large class of attacks. But access to hosting, domain and build system, embedded third-party services and the tools used to generate the site remain open to attack.
Can a static website have contact forms?
Yes, via an external form service or a small, separately operated function. The processing of the data then lies with that service. Clarify data protection and data processing agreements before you embed it.
Can editors maintain a static website themselves?
Yes, with a suitable editing tool. Many solutions offer an interface for editing, from which the site is then regenerated. For teams that change a lot of content daily, however, a classic CMS is often more convenient.
Is switching worthwhile for an online shop?
Usually not completely. Shopping cart, customer account and payment need server-side logic. It is possible to serve parts such as guides or company pages statically and run the shop separately.