Security notes

A live site locked down page by page, without breaking a film, a language or a form.

kunjancollective.com is a nine-language site with drone films, a 3D globe, a hidden DJ set, a studio and a private dashboard. It had one loose security policy for every page, and leftovers from two earlier platforms. These notes cover what changed and how. They’re written so a site owner can follow them, because the method transfers to other sites.

What was there

• One rule for every page. The site-wide policy allowed inline script on every page, so a browser would run injected script as readily as the site’s own.
• Two earlier platforms, still partly online. Files from a WordPress install and a Weebly publish were still on the server. One was a forgotten page with a script-injection flaw. Four old pages were still listed by search engines, showing outdated services.
• Nothing to stop it drifting. Any future update could quietly break a page, or loosen the rules again.

How it was done

1Write down what each page actually runs.

A Content Security Policy is a list the browser enforces: which scripts may run, and where a page may load images, fonts and data from. Every page was read, and its scripts, fonts, images and outside services were listed. The globe needs its map-tile servers; the case study runs no script at all.

2Fingerprint the page’s own scripts.

A script written into the page itself gets a fingerprint: a SHA-256 hash of its exact text. The browser runs it only if its fingerprint is on the list. Change one character and it stops running, and so does anything injected.

3Test before enforcing.

Each policy first went live in report-only mode, where the browser reports what it would have blocked but blocks nothing. Every page was exercised: the films and the language switch, the globe, the studio’s animations and the dashboard’s states. Nothing from the site’s own code was reported, and only then were the policies switched on.

4Handle pages a server builds.

The private dashboard is assembled by the server on every visit, and one of its lines has six possible versions. The policy lists all six fingerprints, worked out from the server’s own code rather than guessed from one visit.

5Clear out what nobody uses, carefully.

• Each leftover was checked for anything still pointing to it before it was touched.
• Files were moved to an offline folder, not deleted.
• Old addresses that might still have links pointing to them now redirect permanently (301) to the right place on the current site, so visitors and search engines land somewhere real.

6Keep it from drifting.

A small checker reads each update before it’s uploaded and prints the exact policy lines that must change, or “no change”. It runs again afterwards against the live site. Before it was used, three separate AI review passes tried to break it, and every problem they found was fixed.

7Check against what’s deployed.

Every step was checked against the live site’s real responses, not against what a tool said it had done. That caught two mistakes before they reached visitors: a redirect that pointed at an anchor that didn’t exist, and a proposed policy that would have broken the studio’s images and video.

How this was built, stated plainly

The work was done with agentic AI tooling, directed by Kunjan. One session wrote and verified the policies, one applied each server change through the browser, and one builds the studio’s updates. Kunjan approved the copy and reviewed every server change. Every configuration edit was preceded by a backup, and leftover site files were moved offline rather than deleted.

Content Security Policy (CSP Level 3) · SHA-256 hashes · Report-only testing · Apache .htaccess · 301 redirects · Mozilla Observatory