The cover image for this post is by Alvaro Reyes
I’ve had an idea for a series floating around in my head for a while:
"baking security into a new website, as soon as a client approaches me"
I even ended up rubber ducking this idea in a recent comment thread:
Those who have been keeping up with my writing will know that I’ve written about this topic before, but always from a more theoretical view:
But in this series, I’ll be taking you through the whole process. From no webapp all the way up to a webapp with security headers, with everything in between.
Aside from the fact that I do this for every webapp that I create, I’ve noticed that almost no one who talks about these things covers the middle step - which is the pain that you feel when the CSP still doesn’t work, or when the marketing person wants to add an insecure feature to the site without checking with you first (which is the most likely thing).
Seriously, you’ll probably spend the most time trying to figure out where all of your disperate JS and frames are loading in from, and will be scratching your head as to why these things are being loaded in. In that way, creating a CSP alone can help with performing a sort of spring clean on your application, but we’ll get to that in a later post.
What Can You Expect From This Series?
I’d say that you can expect practical advice for implementing recommended security headers into your web application, by example.
Exactly how you add these headers will differ, depending on which technology you’re building your webapp with. So I won’t spend much time on actually how to add them to your app (though most technologies offer a similar approach).
I’m going to be building a real app, for a real client of mine, and will document the process. I’ll also link to a dev.to specific build of the app, as I’m building it, so that you can all see it being built up.
(I’ll also provide the source code)
So stick around, watch this space, and you might learn a few things - hopefully.