Skip to content
Filter

Type at least two letters.

Locking it down before writing a word

Before the first real post, I sealed the site: a strict browser policy, default-deny data, and three things that broke on the live site.

Dev
· 2 min read
DraftedSecurityTrue story

Before the first real article went up, I wanted the site’s security settled. Once there is writing on a site, people start to trust it, and that is a bad time to find a hole.

The Browser Policy

The biggest single protection is a Content-Security-Policy: a list that tells the browser where a page is allowed to load things from.

Without a policy
If anyone ever slips a script into a page, the browser runs it.
With a policy
Anything not on the list is refused, whoever put it there.

Around it sit smaller settings: pages served only over HTTPS, no way to put the site inside someone else’s page, and no access to the camera, microphone or location. A check in the build loads real pages in a real browser and fails if the policy is ever broken.

The Data Is Closed by Default

The database starts from “no” and each rule opens only what is needed. A reader can reach only their own small record. Messages can be created only by a server function that checks who you are and refuses spam. And I tightened one more thing: I cannot read your bookmarks or reading progress either. Nobody can.

Three Things That Broke

The strict policy was tested against my local copy of Firebase, which cannot reproduce everything the real one does. So the real site showed me three surprises.

  1. Before launch
    A tiny Google image
    The Firestore client quietly requests a small image from Google to check its connection. My policy blocked it, so I allowed that one address and nothing else.
  2. Right after a deploy
    Missing scripts
    Pages kept for up to an hour in the browser still pointed at script files the new deploy had replaced, so they returned 404. The cause was a caching rule that did not match page addresses. Pages are now checked every visit.
  3. After a hard refresh
    A blocked Google script
    Sign-in tried to load a script from Google that exists only for the popup sign-in I had already decided not to offer. I removed the popup helper, so it never asks.

These surprises are the reason I trust a strict policy: it does not let a mistake pass quietly.

Everything Around the Code

The rest is less visible. Installs use exactly the versions in the lockfile. The deploy uses a pinned version of the Firebase tool, not “latest”. Workflow tokens are read-only except in the two jobs that publish. A weekly check audits the dependencies and scans the code, and Dependabot proposes updates but never merges one.

Security is a set of small refusals, written down before they are needed.

Comments

Private

Only you and the author can see what you write here. The author replies, and you can answer back.