One Coalescent Security
Learn
A free course on preventing the attacks that happen most, for owners, staff and the people who build software.
The Course
Thirteen short lessons on stopping the attacks that happen most, each shown on our own sites. Prevention only.
1Passwords and Signing In
Most break-ins start with a stolen or guessed password. Leaked passwords from one site are tried on every other site automatically, within hours.
Prevent It
- Use a different password for every account, kept in a password manager.
- Turn on two-step sign-in everywhere; prefer passkeys or an authenticator app to text messages.
- If you build sign-in: store passwords only as slow, salted hashes (Argon2id or bcrypt), never as text.
- Limit how fast anyone can guess: slow down and lock out after repeated failures.
On Our Range
earth1.co keeps passwords only as scrypt hashes, each with its own random 16-byte salt, and after ten tries from one address it answers "Too many attempts" instead of checking more. e1-4.com signs people in by voice, and seals each stored voiceprint with AES-256-GCM under a key that lives only on the server.
Could someone who knows one of your passwords get into any other account?
2Phishing and Tricks
The easiest way in is to ask. A convincing email, message or call gets someone to type a password, approve a sign-in or pay an invoice.
Prevent It
- Never sign in from a link in a message; go to the site yourself.
- Read the sender's real address and the link's real domain before acting.
- Confirm any request for money, codes or access through a second channel you already trust.
- Never share a one-time code. No real service will ask you for it.
On Our Range
earth1.co's own reset email links only to earth1.co, and the link stops working after an hour, so an old or forwarded message is worth nothing to anyone who finds it.
Would you notice an email from "0necoalescent.app"?
3Updates and Dependencies
Old software has published flaws with ready-made attacks. Most code in a modern app is other people's packages, and one bad package reaches everyone who installs it.
Prevent It
- Turn on automatic updates for your phone, computer, browser and server.
- Commit lockfiles and pin versions, so builds install exactly what you reviewed.
- Run a dependency audit (npm audit, pip-audit) on every build and fix what it finds.
- Check a package's name, owner and age before adding it; look-alike names are a known trick.
On Our Range
earth1.co, e1-4.com and this site are built from one repository with one committed lockfile, so every build installs exactly the versions that were reviewed, and nothing new arrives unseen.
When did each of your servers last install updates?
4Injection
When text from a visitor is pasted into a database query or a system command, a visitor can write their own query or command. It is one of the oldest and most damaging flaws.
Prevent It
- Use parameterised queries for every database call; never build SQL by joining strings.
- Never pass visitor text to a shell; call programs with fixed arguments.
- Check input against what is allowed (an allow-list), not against what is forbidden.
- Give the app's database user only the rights it needs.
On Our Range
earth1.co's database layer sends every value, even the names of the fields being searched, as a numbered parameter ($1, $2 …), so nothing a visitor types can become part of the SQL. The only number written into a query is a row limit that is already an integer.
Is there any place your code joins text into a query or a command?
5Cross-Site Scripting
If a page shows something a visitor wrote without escaping it, that visitor can run their script in everyone else's browser and act as them.
Prevent It
- Escape everything you show, for where it goes: HTML, attributes, URLs and scripts each differ.
- Insert text as text (textContent), never as HTML (innerHTML).
- Send a Content-Security-Policy that allows only your own scripts.
- Mark sign-in cookies HttpOnly, so a script cannot read them.
On Our Range
e1-4.com shows no visible words at all, and React escapes everything it renders. earth1.co inserts raw HTML only for maths typeset by KaTeX and structured data from its own pages, never for anything a visitor wrote. Both send a Content-Security-Policy.
What happens if someone's name is <b>bold</b> on your site?
6Who May See What
Broken access control is the commonest serious flaw on the web: a page or API that checks who you are, but not whether you may see this particular thing.
Prevent It
- Deny by default; allow each action on purpose.
- Check permission on the server for every request, never only in the app or page.
- Do not rely on hidden links or hard-to-guess numbers to protect anything.
- Test as a second, ordinary account: try to open the first account's things.
On Our Range
earth1.co reads the signed e1_session cookie on the server for every account request, and refuses any request that changes something unless it comes from earth1.co itself (403 otherwise), which stops other sites acting as a signed-in visitor.
If you change the number in a URL, do you see someone else's data?
7Secrets
API keys, tokens and passwords pasted into code, chats or screenshots end up in the wrong hands. Automated scanners find keys pushed to public code within minutes.
Prevent It
- Keep secrets out of code and out of chats; store them in the server's environment or a secret store.
- Give each key the smallest rights and shortest life it needs.
- When a secret has been shown anywhere it should not have been, revoke it and make a new one.
- Scan your repositories, history included, for keys that slipped in.
On Our Range
The keys that sign earth1.co sessions and seal e1-4.com voiceprints live only in the server's environment file, readable by the server alone, never in the code. e1-4.com can rotate its key: the old one still opens old rows, and each row is re-sealed under the new key the next time it is written.
Is any token you have ever pasted into a message still working?
8Connections and Headers
A browser can defend a site well, but only when the site tells it to. A handful of response headers switch those defences on.
Prevent It
- Serve everything over HTTPS and send Strict-Transport-Security.
- Send a Content-Security-Policy with frame-ancestors 'none'.
- Send X-Content-Type-Options: nosniff, a Referrer-Policy and a Permissions-Policy.
- Use the checker on the Security overview to see which are on.
On Our Range
Our Cyberwarfare page grades earth1.co and e1-4.com live, and shows the header code behind each grade.
What grade does your site get?
9Backups and Recovery
Ransomware, a bad deploy or a deleted database all end the same way without a backup that works.
Prevent It
- Keep three copies, on two kinds of storage, one of them away from the server.
- Make at least one copy that the server itself cannot change or delete.
- Restore from a backup on purpose, regularly; an untested backup is a hope.
- Write down who does what when something goes wrong, before it does.
On Our Range
Both sites keep their data in one Postgres database on one server, which is exactly why this lesson matters to us.
How long would it take you to rebuild from yesterday's backup?
10How an Attack Unfolds
Most attacks follow the same path: find out about the target, get in through the weakest point, stay in quietly, reach what is valuable, then take it or lock it. Each step is a chance to stop it.
Prevent It
- Show as little as possible about what you run (no version banners, no open admin pages).
- Close the easy ways in first: reused passwords, missing updates, settings left open.
- Give each account and service only the access it needs, so one break-in does not open everything.
- Watch for the later steps too: new admin accounts, unusual sign-ins, data leaving in bulk.
On Our Range
earth1.co and e1-4.com used to announce "X-Powered-By: Next.js" on every page, which is the first step handed over for free. Both now send nothing.
If someone got into one account today, what else could they reach?
11Logging and Watching
Many break-ins are found months later, by someone else. Without records you cannot tell what happened, and without anyone watching them, records only explain the damage afterwards.
Prevent It
- Log sign-ins, failed sign-ins, changes to accounts and errors, with the time and source.
- Keep logs somewhere an attacker on the server cannot edit.
- Alert on what matters (many failures, a new admin, a sign-in from a new country), not on everything.
- Never log passwords, tokens or other secrets.
On Our Range
earth1.co counts failed sign-in, reset and sign-up attempts per address so it can refuse floods; this site's edge keeps no logs of what visitors search or ask.
Would you know if someone signed in to your admin account last night?
12Floods and Denial of Service
An attacker does not have to get in to do harm: enough requests can knock a site offline. The cheapest floods target the slowest pages, such as sign-in, search and anything that sends email.
Prevent It
- Put the site behind a service that absorbs floods before they reach your server.
- Rate-limit expensive actions per visitor: sign-in, password reset, sign-up, search.
- Cache what can be cached, so most requests never reach the slow parts.
- Set timeouts and size limits on everything you accept.
On Our Range
earth1.co limits password-reset requests to five per address, so its email cannot be used to flood anyone. This site's checker caches each answer for five minutes, so it cannot be used to hammer another site.
Which page on your site is the most expensive to load, and who can call it?
13Testing Within the Law
Testing your own defences is how they get better, but only on systems you own or have written permission to test. In the UK, unauthorised access is a crime under the Computer Misuse Act 1990.
Prevent It
- Test only what you own, or what you have written permission to test, with the scope agreed.
- Publish a way for people to report flaws to you (a security.txt file), and thank them.
- Fix the root cause of each report, then look for the same flaw elsewhere.
- Use a test copy, never the live site, for anything that could break or leak data.
On Our Range
Our range is our own three sites, listed on the Cyberwarfare page. The deeper checks there, for files like /.git and /.env that must never be public, run only on them.
Does your site say how to report a security flaw?