30 Days of Security Testing – Day Eighteen

The challenge for Day Eighteen is – Learn about Security Headers.

If you are testing a web application, the Developer Tools in your browser are your friend.

By pressing F12 on a Windows or Linux machine while accessing a site through a browser (or ⌥⌘I on a Mac), you can see a host of information.

If you visit the Network tab it will initially appear blank, but if you refresh the page with this tab open you will see all of the HTTP requests that were performed to load the webpage on your computer via your browser.

Putting it simply, a HTTP request is an instruction that your browser is sending to the web server, e.g. GET that image, POST my credentials etc.

HTTP requests can have an additional layer of protection in security headers.

These are like further instructions to legitimise the request that the browser is making.

I like to compare this to receiving a package via a courier.

  • A customer orders an item to be delivered to their home (the client/browser).
  • The sender (web server) puts the item into a courier bag and write the address on the bag.
  • The courier collects the package, and checks the address written on the bag against the street name and letterbox number – if they don’t match, the request is denied.
  • The sender may also request that the recipient signs for the package, and the signature is checked for authenticity, or specify that only a certain method of postage is suitable (e.g. secure courier vs public post service)

I found an article here where I learned about six common security headers:

  • Content Security Policy

This header helps to reduce the likeliness of being hit by a cross-site scripting attack by defining approved content sources.

If the request you made was for something from example.com and the returned item came from an unexpected source like fakerequest.com, the request would be denied.

  • X-XSS Protection

This header enables the browser’s inbuilt filter against cross site scripting

  • HSTS – HTTP Strict Transport Security

This header forces browsers to use HTTPS to access the webserver rather than an insecure HTTP connection

  • X-Frame Options

This header restricts the use of i-frames in an application, which can be used in “click-jacking” attacks where a malicious user can apply an i-frame over the top of a button so when a user tries to click the legitimate button they instead click whatever is in the i-frame.

  • X-Content-Type options

This header restricts the browser from “sniffing” the response by specified content type.

E.g. if the response is for a .pdf file you cannot open it as a .txt file and see the code behind it, or alter it.

  • Public Key Pinning

This security header is used to combat fraudulent security certificates.

The web server issues a number of public keys associated with a valid security certificate, and if the client request doesn’t include the required public key(s) the request is denied.



Thanks for reading my post and following my progress through the 30 Days of Security Testing.

For more on Security Testing please visit here  or any of my other ramblings visit here

Feel like joining in? Sign into the WeTest Slack group and get involved!


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Blog at WordPress.com.

Up ↑

%d bloggers like this: