Plain explanations of the technical words in the rules. Each one says which rules use it. On the website, point at a rule number to see the rule.
Accessibility statement (rule 45Rule 45. Always. Publish an accessibility statement. Only if you hold personal data: publish a privacy notice. Only if you use cookies: publish a cookie policy. Only if you have accounts or payments: publish terms that explain clearly how to cancel.). A page on your site saying how accessible it is, what you know doesn't work yet, and how people can contact you about problems.
Argon2 and bcrypt (rule 26Rule 26. Always. Encrypt all traffic with TLS 1.2 or newer, the padlock in the browser. Only if you store passwords or sensitive data: scramble passwords with Argon2 or bcrypt, and encrypt the data you store.). Ways of scrambling passwords before you store them, so that even if your database leaks, the real passwords can't easily be worked out.
ASVS (rule 22Rule 22. Always. Meet level 1 of OWASP's security checklist for apps (ASVS). Only if you hold personal, health or payment data: meet level 2. Only if it's a mobile app: also meet OWASP's mobile checklist (MASVS).). The OWASP Application Security Verification Standard. A list of security checks for web apps, split into levels. Level 1 is the basics every app needs. Level 2 is for apps that hold personal or sensitive data.
C2PA Content Credentials (rule 37Rule 37. Only if your AI makes images, audio or video: label them with C2PA Content Credentials, a tag inside the file that shows AI made it.). A label stored inside an image, audio or video file that shows it was made or changed by AI.
Consent banner (rules 15Rule 15. Only if you have visitors from the EU or UK and use optional cookies or tracking tags: don't load anything optional until the visitor says yes. and 16Rule 16. Only if you show a cookie banner: put "Reject all" and "Accept all" side by side on the first screen, looking exactly the same.). The pop-up asking visitors if they accept optional cookies. In the EU and UK, optional cookies can't load until the visitor says yes.
Consequence Scan (rule 2Rule 2. Always. Before you design anything, think through who your product could harm and how. This is called a Consequence Scan. Fifteen minutes is enough for a small site or feature. Give it up to an hour if the product handles personal data, could be used by children or uses AI. Write down the biggest risks and how you'll deal with each one.). A short meeting, or a quiet 15 minutes on your own, where you think through who your product could hurt and how, before you build it.
Cookie scan (rules 20Rule 20. Only if you use optional cookies or tags: check every cookie your site sets every three months, and again whenever you add a plugin or tag. and 33Rule 33. Always. Before every release, run a security scan on the live site (DAST), an accessibility check and a dark pattern review. Only if users log in: also test that each type of user can only reach what they should. Only if you use tracking: also check your cookies.). A check of every cookie and tracking script your site loads, so you know nothing runs without permission.
Dark pattern (rule 10Rule 10. Always. Don't use dark patterns, the design tricks that push people into things they didn't mean to do, and don't use guilt-trip wording like "No thanks, I don't like saving money". Check your screens against the examples at deceptive.design.). A design trick that pushes people into doing something they didn't mean to, like a hidden "Cancel" button or a pre-ticked box. Also called a deceptive pattern.
DAST (rule 33Rule 33. Always. Before every release, run a security scan on the live site (DAST), an accessibility check and a dark pattern review. Only if users log in: also test that each type of user can only reach what they should. Only if you use tracking: also check your cookies.). Dynamic application security testing. A tool that attacks your live site the way a hacker would, to find holes. ZAP is a free example.
Dependency (rule 28Rule 28. Always. Use as few outside packages and plugins as you can, pick well-maintained ones, and lock their versions in a lockfile.). Code written by someone else that your project uses, like a library, package or WordPress plugin.
DPIA (rule 3Rule 3. Only if you handle personal data, especially health, biometric or payment data: write down the privacy risks and how you'll reduce them before you build. This is called a privacy risk assessment (DPIA).). Data protection impact assessment. A written check of the privacy risks in a project, required by GDPR when you handle risky data.
GPC (Global Privacy Control) (rules 17Rule 17. Only if you have visitors from the US and you sell or share their data or run targeted ads: respect Global Privacy Control, a browser setting that says "don't sell my data", and show a "Do Not Sell or Share" link. and 18Rule 18. Only if you have visitors from the US and use tracking: ad and analytics pixels follow rule 17. But never record visitors' screens (session replay) or chats without telling them and asking first, and never put ad pixels on sensitive pages, like health, money, children's or account pages.). A setting in some browsers that tells websites "don't sell or share my data". Several US states require sites to respect it.
"Do Not Sell or Share" (rule 17Rule 17. Only if you have visitors from the US and you sell or share their data or run targeted ads: respect Global Privacy Control, a browser setting that says "don't sell my data", and show a "Do Not Sell or Share" link.). A link US privacy laws require on sites that sell or share personal data, so visitors can opt out.
Lockfile (rule 28Rule 28. Always. Use as few outside packages and plugins as you can, pick well-maintained ones, and lock their versions in a lockfile.). A file that records the exact version of every dependency, so your project doesn't silently pick up a new, possibly broken or malicious, version.
Manipulation Matrix (rule 55Rule 55. Always. Pass the Manipulation Matrix: only build something if you'd use it yourself and it truly makes people's lives better.). Nir Eyal's test for habit-forming products. Ask two questions: would I use this myself, and does it really improve people's lives? Only build it if both answers are yes.
MASVS (rule 22Rule 22. Always. Meet level 1 of OWASP's security checklist for apps (ASVS). Only if you hold personal, health or payment data: meet level 2. Only if it's a mobile app: also meet OWASP's mobile checklist (MASVS).). The OWASP Mobile Application Security Verification Standard. Like ASVS, but for mobile apps.
MFA, passkeys and security keys (rule 24Rule 24. Always. Protect every account that touches your code, hosting or packages with a login that can't be phished, like passkeys or security keys.). MFA means logging in with something more than a password. Passkeys and security keys are the strongest kind, because they can't be tricked by fake login pages.
NIST SSDF (rule 21Rule 21. Always. Follow the good habits in NIST's Secure Software Development Framework (SSDF), a free US guide to building software securely.). The US Secure Software Development Framework. A set of good habits for building software securely, from planning to release.
OWASP (rules 22Rule 22. Always. Meet level 1 of OWASP's security checklist for apps (ASVS). Only if you hold personal, health or payment data: meet level 2. Only if it's a mobile app: also meet OWASP's mobile checklist (MASVS). and 38Rule 38. Only if you use AI: treat everything that goes into the AI as untrusted, and guard against the risks in OWASP's Top 10 for AI apps (the LLM Top 10).). The Open Worldwide Application Security Project. A non-profit that publishes free security standards and guides.
OWASP LLM Top 10 (rule 38Rule 38. Only if you use AI: treat everything that goes into the AI as untrusted, and guard against the risks in OWASP's Top 10 for AI apps (the LLM Top 10).). OWASP's list of the ten biggest security risks in apps that use AI language models, like prompt injection.
Penetration test (rule 34Rule 34. Only if it's a big launch, or the product has been live for a year: get a penetration test, where an expert tries to break in. Also review your threat model and practise restoring from a backup.). Paying or asking a security expert to try to break into your product, so you can fix what they find.
Red-team (rule 42Rule 42. Only if you use AI: try hard to make it misbehave before launch and after any big change. This is called red-teaming.). Deliberately trying to make your AI misbehave, say harmful things or leak data, before real users do.
Regret test (rule 56Rule 56. Always. In every dark pattern review, ask the regret test question: would people regret using this feature if they understood how it works? If yes, remove it.). Nir Eyal's question: if people understood exactly how this feature works, would they regret using it? If yes, change it or remove it.
SAST (rule 32Rule 32. Always. Scan every code change automatically: the code itself (SAST), the packages it uses (SCA), and for leaked secrets and unsafe settings.). Static application security testing. A tool that reads your code and flags common security mistakes. Semgrep is a free example.
SBOM (rule 29Rule 29. Always. Give every release an SBOM, a list of everything inside it in CycloneDX or SPDX format, and a digital signature.). Software bill of materials. A list of every dependency in a release and its version, like an ingredients label. CycloneDX and SPDX are the two common formats.
SCA (rule 32Rule 32. Always. Scan every code change automatically: the code itself (SAST), the packages it uses (SCA), and for leaked secrets and unsafe settings.). Software composition analysis. A tool that checks your dependencies for known security holes. GitHub's Dependabot is a free example.
Secrets manager (rule 25Rule 25. Always. Never put passwords, keys or other secrets in your code or logs. Keep them in a secrets manager and use tokens that expire quickly.). A safe place to store passwords and API keys, instead of writing them into your code.
security.txt (rule 46Rule 46. Always. Publish a security.txt file and a short page explaining how people can report security problems to you.). A small file on your site at /.well-known/security.txt that tells security researchers how to report a problem to you.
Session replay (rule 18Rule 18. Only if you have visitors from the US and use tracking: ad and analytics pixels follow rule 17. But never record visitors' screens (session replay) or chats without telling them and asking first, and never put ad pixels on sensitive pages, like health, money, children's or account pages.). A tool that records what visitors do on your site, like mouse movements and clicks, so you can watch it back. It can capture personal details, so it needs consent.
Signature (signed release) (rule 29Rule 29. Always. Give every release an SBOM, a list of everything inside it in CycloneDX or SPDX format, and a digital signature.). A digital stamp on a release that proves it came from you and wasn't changed along the way.
Strictly necessary cookies (rule 15Rule 15. Only if you have visitors from the EU or UK and use optional cookies or tracking tags: don't load anything optional until the visitor says yes.). Cookies a site can't work without, like keeping someone logged in or remembering their basket. These don't need consent.
Threat model (rule 4Rule 4. Always. Make a simple threat model. Write down what an attacker might want from your product, like customer data or admin access, and how you'll stop them.). A simple list of what an attacker might want from your product, how they'd try to get it, and how you'll stop them.
TLS (rule 26Rule 26. Always. Encrypt all traffic with TLS 1.2 or newer, the padlock in the browser. Only if you store passwords or sensitive data: scramble passwords with Argon2 or bcrypt, and encrypt the data you store.). The encryption behind the padlock in the browser's address bar. It keeps data private on its way between the user and your server.
WCAG 2.2 AA (rule 44Rule 44. Always. Meet the WCAG 2.2 AA accessibility standard, and test it using only a keyboard and with a screen reader.). The Web Content Accessibility Guidelines, the main standard for making sites usable by disabled people. AA is the level most laws ask for.
Wellbeing measure (rules 5Rule 5. Always. Pick one number that shows your product is really helping people, and track it. "Time spent in the app" is never the goal. and 52Rule 52. Always. Check your wellbeing number from rule 5 every month, and fix whatever is hurting people.). One number that shows your product is really helping people, like "tasks finished" or "problems solved", instead of time spent.