Static vs Dynamic websites - the security perspective

Let’s start off with a bit of history. In the early days of the internet most websites were hand coded in HTML. Since writing HTML documents were deemed too difficult for most content writers of the time, HTML generator software (think Dreamweaver) were created to help content writers. The generated HTML files were then uploaded to a server (remember FTP?). Apart from ease of use, collaboration and other factors, the security risk exposure was down to the quality and maintenance of the web server, the hosting environment and your FTP login.

A few problems arose with this model:

• Due to browser incompatibilities and different devices dynamic layouts and fonts were needed.
• Some content needed to be dynamic - counts, shopping carts, forms, comments etc.
• Collaboration and syncing of content between content writers were difficult to manage.

To resolve the issue of dynamic content, server side scripting (CGI, ASP, JSP, PHP, Python, Perl etc.) was introduced.

At first, minimal scripting was used but then content management systems (CMS) like Plone, Joomla, Wordpress, Drupal to name but a few were developed - all requiring huge server side code bases.

The result is that from a security point of view the risk exposure is currently expanded to the version of server side scripting language used (and all it’s compiled in OS dependencies), the database as well as the version of the CMS used (there is a very long list of vulnerabilities for each). Enter the era of the “script kiddie” and “you are 0wned”.

One could argue that all modern browsers currently support HTML5, CSS and JavaScript. These powerful technologies solve most dynamic content problems (and shift the computational load to the browser as a bonus, allowing for better scalability). Furthermore very little server side code is needed. Server side code should be restricted to the business logic of the web application - and very few “content” centered websites have even this requirement.

That leaves the part of writing content and collaboration. This is easily solved with Markdown, version control systems like git and static site generators like Jekyll and Hugo to name but a few.

Of course this shift places the largest part of the security burden to the browser…