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”.
Of course this shift places the largest part of the security burden to the browser…