Some Thoughts on Static Sites and Security

Some Thoughts on Static Sites and Security

This post is more than 2 years old.

I've been chewing on this blog post for a little while now and while I'm waiting for a keynote to start I thought I'd spend some time to write it up. Let me preface this blog entry by making it very clear: I am not a security expert. I think I have a good handle on security issues at the level every developer should, but it is not my primary role, so take the following with a grain of salt. And while I always say this, please be sure to comment with suggestions and corrections on this topic.

Let's begin by defining the "security space" I'm discussing here. I have a site, let's say this site, and I want to ensure that:

  • no one can modify the content here
  • no one can access anything I do not want them too

Never, ever, put security in the corner

Static sites sound like they would be much safer, or at least somewhat more safe, than other deployment options. And I think that's right (for the reasons I'll lay out below). But you never, never, simply skip considering security. Every single project should have security review/checking/etc as part of the process from day one. Period. It always needs to be part of the conversation between developers and clients and an integral part of the development process. Period.

Are static sites safer?

By removing the app server from the equation, the potential vulnerabilities are greatly reduced. Every app server has had security issues of some sort over time, requiring the developer to ensure they've properly updated, patched, and locked down the proper settings. Flat files simply don't need this.

Also - many app servers rely on some form of persistence, whether that be a NoSQL solution like Cloudant or a traditional database like MySQL. Removing them from the equation means no SQL injection attacks or other database leaks.

But...

You have to host your site, right? If the client puts those simple, flat files on an Apache server configured to run PHP then you're still running in an environment where an attack can happen.

For this site, I used Netlify and Amazon S3. I trust the engineers behind these services much more than I trust myself, but I have to be aware of their services and pay attention to any security issues that may be found on them. The same would apply for GitHub too.

Speaking of GitHub, my site's public content is driven by checkins to my GitHub repo. If my credentials were hacked then that would be a vector to change the contents here.

So yeah - I've removed ColdFusion, PHP, Mongo, etc from the equation, but I'm certainly not at 0% risk.

Dynamic Aspects

Many static sites actually contain quite a few dynamic aspects. I've blogged about, and presented on, adding dynamic aspects back to static sites via services like Disqus and Formspee, both options are in use here. If someone were to find a way to attack Disqus than that would impact me as well. Ditto for my form processing service. Every one of these services I add back to a static site is yet another thing I've got to keep tabs on.

More reading

So those are my thoughts. I think - obviously - you can also do things like adding https, and I found a great article that covers those details here: Which security measures make sense for a static web site?

I'd love to hear from people working with static sites in terms of what steps they are taking when it comes to security. Do you have a checklist? What do you look for? Let me know in the comments below!

As a final note, don't forget that if you want to learn about static sites in general, the book I wrote with Brian Rinaldi was just released. I may be biased, but I think it's pretty great: Working with Static Sites

Raymond Camden's Picture

About Raymond Camden

Raymond is a senior developer evangelist for Adobe. He focuses on document services, JavaScript, and enterprise cat demos. If you like this article, please consider visiting my Amazon Wishlist or donating via PayPal to show your support. You can even buy me a coffee!

Lafayette, LA https://www.raymondcamden.com

Archived Comments

Comment 1 by Vic Cekvenich posted on 3/21/2017 at 4:31 PM

I have deployed a few static sites. Mostly it means you fetch data and bind. So API. Securing API is more work.
ps: Some ex, WIP https://github.com/topseed/...

Comment 2 (In reply to #1) by Raymond Camden posted on 3/21/2017 at 4:34 PM

Ah good point. I did mention third party 'services', which are APIs of course, but I should have specifically called out APIs as well. You may have a static site on alpha.foo.com using an API you have running on beta.foo.com.

Comment 3 by Sequoia M. posted on 3/21/2017 at 5:12 PM

What form processing tool do you use and how could that be an attack vector?

Comment 4 (In reply to #3) by Raymond Camden posted on 3/21/2017 at 5:17 PM

I'm using Formspree. Right now they validate by the referer and email address being sent to. That seems reasonably secure to me. But I at least thought about it before using it. :)

Comment 5 (In reply to #4) by Raymond Camden posted on 3/21/2017 at 5:20 PM

I can see one way I could abuse this though. Formspree (and other form services) also allow for Ajax submissions. I'm not using that now, but imagine I was. I could then use the browser console to manipulate the function to *attempt* to send hundreds of emails to myself. Not sure what they (Formspree, etc) would do when that occurs, but its one way a person could attack.

Or heck - just script a Selenium thingy to run form fillers and submit a bunch. If I were paying per a certain level of responses, that would cost me $$.

Comment 6 (In reply to #2) by Vic Cekvenich posted on 3/22/2017 at 10:13 PM

Even running on same subdomain... you have to secure.

Comment 7 by jesse650 posted on 3/29/2017 at 4:04 AM

Security should be built it. It should *not* be a checklist item.
If anything, the security items should be check at the start of a project.
If "security" is in the middle of the process, it is likely to be missed.
Any doubts on this last statement, them remember all the times you've
mis-spelt a word, and had to go back an correct it... sometimes months later.
Now exchange "word" with "security item".

On Unix/Linux/BSD systems you ALLWAYS need to check your file permissions.
If you have a collaborator, then 0664 else 0644.
On Windows/OSX it is a bit more labourious. Remember the issue is
who can and cannot edit the "flat file".

Database injections is but one vector of attach. If you require
dynamic data, a DBaaS (DataBase as a Service) works. Many LAMP and WAMP
systems work this way. There is a bit more pain in using the DB,
but the headache of running an online DB is reduced.

LAMP - Linux Apache Mysql PHP

WAMP - Windows Apache MsSQL PHP

With *nix, if you run your own server and someone breaks-in,
give them an account, buy them a beer and meet them in person.

With window, if you run your own server and someone breaks-in,
call M$ bitch an whine - they may give an M$ Admin Cert for free.

All the Best