Are your internal tools exposed to public misuse? Passwords aren’t always the answer. At WebExpo 2024, Michal Špaček showed how Sec-Fetch headers and Content Security Policy (CSP) can lock down your app. With no extra login required.
Software developer and application security engineer Michal presented “Use fetch metadata to solve modern problems”, where he discussed how recent advancements, particularly the introduction of Sec-HTTP headers and the robust utility of CSP, have transformed web security and trustworthiness.
Michal opened his talk with a familiar type of story. You need a brand-aligned “email signature generator” to ensure your company emails look sharp and consistent. And next thing you know, you’re starring in a scammer’s pitch. He recounted how colleagues built a public-facing web app for generating internal HTML signatures. “I looked at the application, and it was like, hmm, okay. It was a public application. It wasn’t protected by a password”, he said, recalling how fraudsters could exploit it to impersonate colleagues and dupe clients.
Rather than burdening users with yet-another-password, Michal asked: could modern browser features secure the tool without another login? His answer would reshape how we think about everyday web-security problems.
Fetch metadata: The browser’s own security signals
Michal introduced fetch metadata, a suite of new Sec-HTTP headers that tell your server how the browser intends to handle each resource. “With fetch metadata, the server can actually learn what the browser will do”, he explained, demonstrating Sec-Fetch-Dest: iframe and Sec-Fetch-Site: same-site in Chrome DevTools. By embedding the generator inside an authenticated wiki iframe, Shoptet ensured that only logged-in staff could invoke it. Any request lacking the correct headers simply failed.
“If people need to authenticate into the wiki page, then they will already be authenticated for the business card generator”, Michal remarked.
He warned that no single header is foolproof, and Sec-Fetch-User (which flags user-initiated actions) can misfire, but combined signals offer a reliable defence against cross-site misuse.
Bridging to CSP: Layered, standards-based security
Once the team had fetched metadata enforcing context and origin, Michal turned to Content Security Policy to lock down sub-resources. By setting Content-Security-Policy: frame-ancestors ‘self’ wiki.shoptet.com, only the wiki domain could frame the generator. Likewise, strict script-src directives (with Subresource Integrity hashes) prevented unauthorised scripts, while blocking JavaScript skimmers at the gate.
Thanks to them and thanks to his favourite Content Security Policy (CSP), the old saying, “Fast, good, or cheap – pick two”, is no longer true because you can have all three.
A roadmap for trust and how to get there
Michal wrapped by reminding developers that browser vendors have broadly supported these headers for years (Chrome and Firefox since 2021; Safari joined in March 2023). He quipped that only Opera on Android still lagged, and when asking the room, nobody in the audience raised a hand…
His closing call was simple: adopt HTTPS everywhere, audit your resource loads, and lean on fetch metadata and CSP rather than passwords and proprietary hacks. In Michal’s words, “Please use fetch metadata for whatever you want.” The whole point is to help ensure the web is secure, fast and user-friendly in equal measure.
For teams drowning in credential fatigue or battling client-side script attacks, Sec-Fetch headers and CSP offer a lean, standards-based shield. And if you ever think “just another header” won’t cut it, remember the email-signature generator: modern problems demand modern solutions.
Be sure to check out Michal’s full talk and slides below and get ready to take some notes!