Automatic Testing for Security Headers

Today, performing unit tests has become a standard in many development teams for automatically performing various tests on code (e.g. as a compulsory part of the build process). Especially in agile development, the existence, completeness and quality of such tests is a critical aspect for ensuring that the application is still working after each commited change.

Although unit tests are very often created and used, security relevated tests (aka security unit tests), are still performed very rarely. Such tests can be used to ensure, that code-based security controls (e.g. for authentication, access controls, validation or crypto) are working correctly. Especially for security relevant APIs the existence of proper security unit tests are critical. Also, we can use a unit tests to integrate external security code scanners (e.g. Fortify, Veracode, etc.) and combine it with a proper scan policy for the environment or type of application.

This is not a new concept. Stephen de Vries outlined the need for security unit tests in an OWASP speach titled “Security Testing through Automated Software Tests” in the year 2006.

But we can do even more. We can use the unit testing framework (e.g. JUnit for Java, NUnit for .NET or PHPUnit for PHP) to perform security integration tests as well. These are perhaps not executed with every build, but at least before the code is deployed in production. The following snippied shows an example for a JUnit test based un Apache HTTP Client that performs a test that checks the existence and correct value of a X-Frame-Options response header of a specific Web server:

We can now execute this test case within our development UI (e.g. Eclipse) or on the command line using mavens surefire plugin. Let’s see how it works with (instead of “”). Google does set a X-Frame-Options header, but uses the value “SAMEORIGIN” instead of “DENY”. So our second assert should fail:

Pretty much what we expected. Besides this use case, we could use such integration tests for a large number of additional security checks:

  • Verifying input validation controls
  • Verifying output validation controls< (e.g. an “XSS Detector”)
  • Verifying password policy/complexity checks
  • Verifying session handling and session id lifecycle
  • Verifying access controls
  • Checking for inseure configuration (e.g. error handling)

In the next couple of weeks I will give a few practical examples for such tests and will show how we can integrated various testing frameworks such as Selenium or Watir for that.


About Matthias Rohr

Matthias Rohr, CISSP, CCSLP, is the founder and lead security architect at Secodis. Matthias began working in this field in 2004 and is since a frequent speaker on international AppSec conferences, book author, author of TSS-Web and an active AppSec community contributor. He lives and works in Hamburg / Germany.
This entry was posted in Java, Security Test Automation and tagged , . Bookmark the permalink.

One Response to Automatic Testing for Security Headers

Leave a Reply

Your email address will not be published. Required fields are marked *