BDD-Security already has a scenario to test for site-wide HTTP header security controls. Aspect Security have also published a handy web app with extensive tests for HTTP header security.
Both of these methods test the site-wide HTTP headers, but some headers like cache-control may only be applied to specific pages with sensitive content. So they may not always be applied to the front page of the app.
Luckily, BDD-Security already knows about sensitive content through its configuration for access control tests. So this same information can be re-used to test for cache-controls only on sensitive pages. Here’s how it works:
Firstly, the framework needs to be configured to be able to login to the app as described in the tutorial. Next, we need to tell it which users can access what sensitive content. This is done by first adding the users to the config.xml file:
< users >
< user username="bob" password="password">< /user>
< user username="alice" password="password">< /user>
< user username="admin" password="password">< /user>
< /users>
And then creating methods in the main Java file that are tagged with the @Restricted annotation:
@Restricted(users = {"alice","admin"}, sensitiveData = "[email protected]")
public void viewProfileForAlice() {
driver.get(Config.getBaseUrl() + "user/edit/2");
}
This says that both the users ‘alice’ and ‘admin’ should be able to perform the selenium actions described in the method ‘viewProfileForAlice’, and when they do, then at least one of the HTTP responses captured while executing that method should contain the string ‘[email protected]’
It’s essential for the access control tests, that the ‘sensitiveData’ string is only visible to the authorised users. If user bob were to attempt to access that method, he definitely should not see ‘[email protected]’ anywhere in the responses.
(To perform the access control tests, you would then record selenium actions for every user and define what the sensitive content would be. You can annotate any number of methods with the @Restricted annotation, as long as it’s a no-args method)
Since the framework now knows which content is sensitive, that same information can be used to test for cache-controls using this pre-built scenario that’s included in the transport story:
We can execute just this scenario in isolation with:
./runscenario cache_control_http_headers
The framework will translate all the users in the config.xml and all methods annotated with @Restricted, into a JBehave examples table which is then fed to the scenario above. I’ve added a few more @Restricted methods to the RopeyTasksApplication class used for the demo, so the result would look something like this:
And bob’s your cousin’s father. The cache-control tests are included in BDD-Security as of today.