The Burp Suite User Forum was discontinued on the 1st November 2024.

Burp Suite User Forum

For support requests, go to the Support Center. To discuss with other Burp users, head to our Discord page.

SUPPORT CENTER DISCORD

Does Burp's own browser respect Strict-Transport-Security?

Jeff | Last updated: May 26, 2023 09:08PM UTC

To what extent does Burp's "own" browser respect Strict-Transport-Security once it sees the header... and can this behavior be configured? Put another way... suppose I have project #1 loaded, fetch http://tested-site.org/foo using the browser, and it sees a Strict-Transport-Security header with expiration date a year from now. Will that directive's impact persist: * Across all future Burp projects, until it expires on its own? * Within the current project (until it expires on its own), but every new project has its own browser context (including Strict-Transport-Security), so exiting project #1 & creating project #2 wipes the metaphorical "Strict-Transport-Security" slate clean? * Some other scope and duration that's narrower than, "forever until expiration, unless the installation of Burp and its browser gets deleted and wiped clean"? Is there an option somewhere IN the browser to configure this behavior, or at least defeat/clear/replace a Strict-Transport-Security directive that's already been seen and won't be expiring for a very long time? If Burp's browser has no way to configure this, and/or the only way to clear it is to do a scorched-earth uninstall and reinstallation of Burp and its browser... is there a relatively "clean" way to have Burp's proxy rewrite any such headers so the browser always sees them as "Strict-Transport-Security: max-age=1" (so Scanner and audits won't flag it as a finding, but nevertheless it won't get in my way and leave me unable to subsequently poke and prod at the site at all (via http) using the embedded browser)?

Dominyque, PortSwigger Agent | Last updated: May 30, 2023 08:52AM UTC