Cybersecurity rarely makes good news. It becomes visible when it is already too late: customer data leaks, a transfer lands in the wrong account, or a site will not open during the busiest hour of the week. This topic collects how we look at security at tbskit — the threats that actually succeed, the layers of defence we install on every project, and the small habits that remove the most risk.
Why this is about habits, not only technology
Most incidents that hit small and mid-sized sites do not begin with a vulnerability that nobody had ever seen before. They begin with something known and left open: an old account still active, a password reused across services, a device waiting months for updates, or an urgent request answered without verification.
That is why we treat security as a routine rather than a project. A security project finishes and is forgotten; a routine keeps running and stays cheap: patch, check, revoke access that is no longer needed, and repeat the loop before an incident forces it.
The threat model we use
We do not start from a list of tools. We start from three short questions answered together with the project owner:
- What is worth taking? Customer data, access to payment systems, access to repositories and hosting, or brand reputation. Each one deserves different handling.
- Who might be interested? Fraudsters chasing money, spammers, competitors, insiders leaving a project, or bots that scan the whole internet without targeting anyone in particular.
- Where is the way in? Email and messages, forms and file uploads, accounts with elevated privileges, third-party services, and everyday work devices.
The answers set the order of work. A project that stores payment data gets a different priority list from a company profile site — but both still get the smallest useful version of the same list.
The defence layers we install
No single tool is enough, so we build layers and assume each one can fail.
Identity and access
- Everyone uses their own account. Shared accounts erase any record of who did what and turn someone leaving a project into guesswork.
- Two-factor on every important account — DNS, hosting, repositories, email, and media services — because those are the accounts that can both take a site down and leak it.
- Least privilege by role, reviewed quarterly, including revoking access when someone stops being involved.
Application and code
- Input validation on the server, because validation in the browser is convenience, not security.
- Parameterised queries for every database call, so user input is never part of an executed statement.
- Output encoding and a Content Security Policy, so third-party code cannot run on a visitor’s page.
- Dependencies kept few and updated. Every package is a maintenance contract that never expires — see our code standards.
Infrastructure and network
- HTTPS everywhere, with TLS managed and renewed automatically.
- Security headers (HSTS,
X-Content-Type-Options,Referrer-Policy, and CSP) set at the host level, not left to memory every time a page is added. - Unused surface removed, including stale DNS records, test subdomains, and endpoints nobody calls any more.
- Backups kept separate and tested. A backup that has never been restored is a hope — see how we store and serve sites.
People and process
- Sensitive requests verified on another channel. A request to move money or change access is never answered from a single email alone.
- Short, regular training, using real examples circulating in the audience’s own region rather than theory quizzes.
- A runbook for the bad day. What gets checked first, who is told, and how the state is restored — part of our ops habits.
The habits that remove the most risk
If there is only time for five things, the order is usually this:
- Multi-factor authentication on email, DNS, hosting, and repositories.
- Long, unique passwords for every account, held in a password manager.
- Regular updates for operating systems, applications, plugins, and dependencies.
- Separate backups that can actually be restored, with a rehearsed recovery check.
- Verification of sensitive requests on a channel other than the one asking.
The rest is incremental: tidying access control, switching monitoring on, making sure notifications reach a human, and keeping documentation correct after the person who wrote it moves on.
What we do not promise
Perfect security does not exist, and offering it would be misleading. What we do promise is simpler: measurable risk, explainable decisions, and mistakes that are not punished — because a team afraid to report a problem is more dangerous than the problem itself.
What we publish under Cybersecurity
Articles in this topic go into practical detail: recognising the most common attack patterns, securing accounts and access, tightening application defences, preparing backups that can really be restored, and responding to incidents without panic. Start with the threat map: 15 types of cyber attacks you should know summarises the patterns you are most likely to meet, along with the steps that prevent them.
Related reading: our code standards, the ops habits that keep a system steady, and the guides we maintain.
Want a security check of your site or infrastructure? Tell us what you run and we will start from the shortest list that removes the most risk.
