I had added a Content Security Policy to the app with script-src set to 'self'. The idea is sound: the browser runs scripts that come from my own domain and refuses everything else. I checked that the header was present on the live site, marked the item as done in my notes and moved on.
SvelteKit starts each page with a short inline script. The browser read my policy literally and refused it. The page text and the forms were there, because the server had already produced them. The part of the app that runs in the browser never started. Without it, the screens that refresh themselves every 45 seconds did not refresh, the service worker was never registered, and the Excel import, which parses the file in the browser, could not run at all.
I did not see it, and my earlier security report said the CSP was correct. The reviewer opened the login page in a browser and read the console. It had two errors, each one beginning with "Executing inline script violates the following Content Security Policy directive 'script-src self'", and each one went on to say that a hash or a nonce was required.
The fix is the kit.csp setting in SvelteKit, which adds a nonce to the scripts it generates. Each response gets its own random value, the policy allows that value and my own domain, and the browser accepts the framework's script without allowing every inline script. The inline code that registers the service worker moved to a separate file.
Then a headless Puppeteer session opened the login and privacy pages. The console was empty, the page had started and the service worker was registered. I run that check again after every change to the headers.
The habit I took from it is that a security setting is tested in a real browser, with the console open. A header that exists on the wire tells me nothing about whether the app still runs.
Disclosure: drafted with a local AI model, then reviewed and approved by me. Originally published at https://bbal-blog.kairo-app.workers.dev/when-a-security-header-blocks-your-own-app/
Top comments (0)