Checking My Sites with Security Headers and SSL Labs

While working through the Practical Bug Bounty section on findings and impact, I checked my own sites with Security Headers and SSL Labs.

Two of my sites received C+ grades from Security Headers. I made changes and checked them again, then verified that all the sites I checked had grades of A or higher. The SSL Labs checks also returned A or higher for every site I tested.

It was a useful way to take something from the course and apply it to sites I control. The results gave me a specific set of configuration issues to review and a way to check the changes afterward.

What Security Headers checks

Security Headers examines HTTP response headers and grades the security-related configuration it observes. Those headers can influence how a browser handles content and applies protections when it loads a site.

For my checks, the change from C+ to A or higher is the result I can report. My notes don't contain the individual before-and-after header values, so I'm keeping this account at that level rather than inventing a detailed remediation walkthrough.

A useful follow-up would be to save the response headers alongside the scan results. That would make it easier to explain exactly what changed and check whether a later deployment removed or altered one of the settings.

The details matter more than adding a header just to satisfy a grade. The value has to suit the application, and the browser still needs to load the site's intended scripts, styles, images, and other resources correctly.

What SSL Labs checks

SSL Labs examines a server's TLS configuration. Its rating guide describes certificate checks and evaluation of protocol support, key exchange, and cipher support, with additional rules that affect the grade.

These checks address the connection between a client and the server. They help identify configuration problems in that part of the system, but they don't establish whether the application correctly restricts access to records or handles a sensitive workflow safely.

All the sites I checked received A or higher from SSL Labs. I don't have an earlier failing TLS result in these notes, so there is no before-and-after TLS improvement to claim.

Keep the result tied to what was tested

An A grade describes the result of a particular tool's checks at a particular time. It is useful evidence for that purpose. It doesn't replace testing of authentication, authorization, business logic, or the rest of the application's behavior.

For example, a site can deliver a page over a well-configured encrypted connection while still returning a record to the wrong user. Testing that record boundary requires different evidence than reviewing the connection settings.

There is also a difference between a URL checked by a header tool and every response an application might produce. An error response, an API endpoint, and an authenticated page may behave differently. I would need to check those paths before claiming the same configuration applies throughout the application.

Make the changes easier to verify next time

For a repeatable check, I would record:

The exact hostname or URL and the time of the test.
The tool output and relevant response headers.
The configuration change and the deployment that introduced it.
A repeat check showing the expected result.
A quick check that the site's normal behavior still works.

A regression test could then check selected responses for the intended header values after deployment. TLS configuration also needs periodic review, especially when certificates, hosting, or edge configuration change. Those are follow-up ideas, not checks I'm claiming to have automated already.

This connects back to the course's distinction between hardening observations and demonstrated impact. A finding may be worth addressing on my own site even if it would not qualify for a bug bounty. The decision should be based on the setting, its purpose, and the application's needs.

For this study session, the work I completed was straightforward: check my sites, address the two C+ header results, and verify the new grades. There is still more to test, but these checks gave me a concrete place to start.

The next post follows the course's overview of a web application penetration test, from agreeing on the work to reporting and retesting.

Sources and further reading