Cybersecurity

How the site protects itself, and you

A site that teaches people to run their own systems must set the example. This page shows how breaktherule.org is protected: the flow, the logic and the design, in plain words.

The flow

Three loops run at the same time: one at every visit, one every day, one at every change.

The security flow: at every visit Cloudflare, the code of the site and the browser each protect the visitor; every day four automatic checks look for new weaknesses and write a report; every change is checked and reviewed before it goes live At every visitA visitor, or anattacker, opensbreaktherule.orgCloudflare, in front of the siteEncrypted connectiononly (HTTPS, TLS 1.2or newer, HSTS)Signed domain name(DNSSEC, CAA)Firewall, anti-bot, atmost 20 API requestsevery 10 secondsThe code of the siteThe contact formaccepts a message onlyafter Turnstileconfirms a human sentitLength limits, strictformats, errors failclosedNo account, no cookie,no name, email or IPaddress storedThe browserSecurity headers: runonly the site's ownscripts, never showthe site insideanother pageEvery day, by itselfFour checks run at 05:23UTC: knownvulnerabilities in thedependencies, secrets inthe whole history of thecode, files that mustnever be committed,dangerous patterns in thecodeSerious finding?noNoted in therun summaryyesOne issue is opened andthe maintainer isnotifiedonce alater runis cleanThe issue closes byitselfEvery run ends with areport: openvulnerabilities, today'schecks, what toanticipate. Also whennothing happened.At every changeA change is proposed inthe open, with itsdocumentationAutomatic checks: types,tests, a dry run of thepublication, thechangelogReviewed and approved bythe maintainer?noNothing goesliveyesPublished. A smallsecurity fix in adependency may bepublished by itself,within a strict rule

The logic

  • Layers. No protection is perfect on its own, so there are several, one behind the other, like the walls, the gate and the safe of a castle.
  • Fail closed. When a check cannot run, or cannot answer, the answer is no. A message is refused rather than accepted on trust, and a daily check that did not run counts as a finding.
  • The least data. What is never collected cannot leak: no account, no cookie, and no name, email or IP address kept with a message.
  • Secrets outside the code. The code is written as if everyone could read it, because one day everyone will. The only secret lives on Cloudflare, and the daily checks look for secrets and forbidden files in the whole history of the code.
  • Machines look every day, people decide. Four automatic checks look for new weaknesses every morning and write a report, also when nothing happened. A person reads it and decides.
  • Nothing goes live without an ok. Every change is reviewed and documented before it is published. The one exception is a security fix in a dependency, published by itself only when it is small and every check is green.

The design

Everything is free and open source: Cloudflare's free plan, GitHub's free tools and scanners anyone can download. Nothing calls an AI and nothing needs a paid service, so the same protections can be copied by anyone who runs a small site.

Everything is written down. The project's documentation describes every protection, its status and how to check it from any computer, so that a change nobody expected stands out.

Everything follows the four steps of the site itself: accept the process, understand it, find the part that does not work, break the rule and improve it. The daily report exists to find that part before someone else does.

Found a security problem?

Write to 59495@proton.me, describing the problem and how to reproduce it. The same address is in security.txt, the standard file where a site says whom to tell.