A Little Hardening with Burp Suite

Recently, I dug into Burp, experimenting with some Professional Suite features, when it occurred to me that I had never tested my own website. I had security in mind during the design phase (security by design), using a static website and a Web Application Firewall (WAF), but testing it directly was still worth doing. In this post, I’ll share the vulnerabilities I found and the fixes.

Running Burp

Not being a Burp expert, I won’t turn this into a tutorial. If you’re interested, this TryHackMe room is a good starting point. For my test, I included only my domain in scope, applied a filter to intercept only in-scope traffic, turned on the proxy, and navigated through the site.

After a few minutes, I turned off the proxy and analyzed the data within the Target menu. The Enterprise Edition’s vulnerability scan revealed issues I had overlooked during the initial setup. In the following sections, I’ll detail these findings.

Strict Transport Security not Enforced

HTTP Strict Transport Security (HSTS) prevents users from connecting to the website over unencrypted connections — learn more here. As previously explained here, this website’s current architecture employs CloudFlare as a WAF, configured to enforce secure connections. However, for usability reasons, I initially allowed insecure connections without enabling the HSTS feature, fearing it might deter potential visitors.

Things have changed. I enabled HSTS and set the minimum TLS version to 1.2. Since a big part of this site is about Information Security, there’s no better way to teach than by example. If you try accessing lopes.id through a deprecated browser using insecure TLS versions, you won’t be able to open it.

Frameable Response and Cacheable HTTPS Response

Frameable Response poses a clickjacking threat: A malicious actor could exploit my site to lure victims and compromise their systems, as explained here. I fixed this by configuring my web server through Netlify’s configuration file. This Netlify help page explains how, and I added an extra mitigation against XSS attacks as suggested in the how-to.

The scan also flagged the need for browser-side cache control, which I fixed using this resource. The final section in the configuration file was:

[[headers]]
  for = "/*"
  [headers.values]
    X-Frame-Options = "DENY"
    X-XSS-Protection = "1; mode=block"
    Cache-Control = "no-store"

Takeaways

That sums it up — only low-severity vulnerabilities found, all fixed in minutes. This shows the value of security by design and simpler architectures. It may not apply to every project, but KISS principles apply to security too, and dropping unnecessary features improves your project’s security just by reducing the attack surface.

No matter how carefully you plan and deploy your project, Information Security has to be layered, and security tests fit into [almost] all scenarios. Testing is a reminder that security is a process, not a static state. Running tests periodically matters, since new vulnerabilities keep appearing and projects keep changing — ideally, new tests with each new feature, and preferably in a DevSecOps-automated way.