Extra security of static websites

Jeremy Melis

06-02-2026

Introduction

This blog discusses the practical applications of static websites and explains why, in many cases, they provide additional security compared to dynamic websites. It covers the situations in which static websites are a suitable choice, how they are used in practice, and the advantages they offer in terms of performance, maintenance, and security. In addition, it explains why the absence of server-side code and databases reduces the attack surface, making static websites less vulnerable to common security issues that often affect dynamic websites.

Server-side versus Client-side

Two important terms to remember are server-side and client-side. These terms indicate where code is executed. Client-side code is executed on the user’s computer (the client), usually in the web browser. Server-side means that the code is executed by the computer on which the website is hosted. This computer is called the server, hence the name.

What are static and dynamic websites?

Static websites are websites where no server-side code is executed. This means that the website consists entirely of HTML, CSS, JavaScript, and other client-side programming and scripting languages. The content of a static website is fixed and is not modified based on user input or database data. In principle, every visitor sees exactly the same web page. Static websites are often faster, easier to host, and less prone to security issues, because no server-side logic or database is involved.

A dynamic website, on the other hand, makes use of server-side code. The content of the website is generated by the server and may vary per user, time, or input. Dynamic websites often use a database to store and retrieve data. Websites that use a CMS (Content Management System) are dynamic, because they rely on server-side programming languages. A well-known example is WordPress, which primarily uses PHP in combination with a database such as MySQL. This allows administrators to easily modify content without directly changing the code.

Although static websites themselves do not contain server-side code, they can still perform CRUD actions (Create, Read, Update, Delete). This is done through external services such as APIs. Using JavaScript, a static website can send HTTPS requests to an external backend, such as a REST API or a cloud service. These HTTPS requests are sent from the client’s computer rather than from the server on which the website is hosted.

Security

It can be assumed that all client-side code can be modified by an attacker. After all, this code is executed on the user’s computer, and that user could also be a hacker. Client-side code is therefore inherently untrustworthy and should never be relied upon for critical logic or security.

In the case of a static website, this means that retrieving and storing data cannot take place on the client. A separate server is required for this: a backend that contains only server-side code. At first glance, this may seem like a disadvantage, because it introduces an additional server component. In practice, however, it significantly increases security, as sensitive functionality is completely shielded from the client.

Because the server-side logic is strictly separated from the client, an attacker has no direct access to the core of the system. Even if the client-side code is manipulated, the most critical parts of the application remain protected. This reduces the impact of common vulnerabilities, such as Cross-Site Scripting (XSS).

XSS

In an XSS attack, an attacker can execute malicious JavaScript code in the browser—sometimes even in the browser of another user, depending on the type of attack. The ultimate goal of a hacker is often not the user themselves, but gaining further access to the system, for example by hijacking sessions or abusing administrator privileges. In the worst case, this can lead to code execution on the server.

In many dynamic websites, an XSS vulnerability can therefore have serious consequences. For example, if an administrator clicks on a malicious link, an attacker may gain access to the server-side environment through that session. In systems such as WordPress, an XSS vulnerability can even be a stepping stone to executing code on the server itself, potentially leading to a full compromise of the system.

A concrete example of this can be seen in the case XSS Municipality of Eindhoven (https://melisitsolutions.com/en/writeups/XSS_Eindhoven/). This vulnerability demonstrates how an XSS flaw can be exploited to mislead an administrator. The vulnerability allows an attacker to create a link that executes JavaScript code when someone clicks it. If such a vulnerability had existed in a dynamic website with a tight coupling between client and server, a single wrong click could have resulted in direct access to the underlying server.

With a static website and a strictly separated backend, the damage caused by an XSS attack is usually limited. The attack primarily targets other users (such as through session hijacking or phishing) but does not provide a direct path to server-side code execution. It is precisely this separation that makes static architectures often more robust and secure in practice.

How can you tell whether your website is static or dynamic?

There are several ways to determine whether a website is static or dynamic. Below is a simple explanation.

1. If you programmed the website yourself

  • Dynamic website: If you use programming languages such as Python, PHP, or Java to directly display pages that change depending on who visits the website, the website is dynamic. The content is generated live by the server.

  • Static website: If you only use HTML, CSS, JavaScript, or TypeScript and create the pages in advance, the website is static. The content of the page does not automatically change. Even if the website retrieves data from a server via an API, it remains static, because the page itself is not built live by the server.

2. If you use a CMS

A CMS (Content Management System) such as WordPress or ContentHub always creates a dynamic website, because the server retrieves content from a database and assembles the page at the time of each visit.

3. By looking at the functionality

  • Static website:

    • Pages are created in advance and do not automatically change on the server.
    • The content is usually “fixed,” but may have limited interaction through external scripts or services, such as a login or form.
    • Manual changes are required to update the content.

  • Dynamic website:

    • Pages are generated live by the server, often depending on the user or their actions.
    • Users can log in, post messages, leave comments, or see personalized content without communicating with another server.
    • The content automatically changes based on user actions or other data.

In short:

  • Static = fixed pages, even if data is retrieved from a server
  • Dynamic = pages are generated live by the server for each visitor

Summary

This blog explains the differences between static and dynamic websites, with a strong focus on their practical use and security implications. Static websites consist entirely of client-side technologies such as HTML, CSS, and JavaScript, and do not execute server-side code. As a result, they deliver the same content to every visitor, are faster to load, easier to maintain, and have a smaller attack surface.

Dynamic websites, by contrast, rely on server-side code and databases to generate content in real time, often using content management systems like WordPress. While this allows for greater flexibility and personalization, it also introduces more potential security risks.

A key security advantage of static websites is the strict separation between client-side code and server-side logic. Any sensitive operations are handled by an external backend or API, reducing the impact of common vulnerabilities such as Cross-Site Scripting (XSS). Even if client-side code is manipulated, attackers cannot directly access server-side functionality.