Security at the heart of every project

What "securing" means, and what it does not say

In short: Security is a property of the whole system, not a feature you switch on. A site can tick every technical box and remain vulnerable through its organisation.

The word covers three distinct questions worth separating. Who can access what: authentication and authorisation. What happens if someone gets in anyway: encryption, logging, and the ability to restore. And what happens if nobody gets in but the service stops: availability, often left out of security discussions although it belongs there.

A common confusion treats security as a layer added at the end of a project. It is mostly decided at design time: which data is collected, where it lives, who sees it, how long it is kept. Those choices determine the surface to defend. The technical measures that follow only protect what has already been decided.

None of these measures makes a system impregnable, and a page implying otherwise would be lying. They make an attack more expensive, slower and more visible. That is the real objective: to shift the ratio between an attacker's effort and what they obtain.

Encryption: in transit and at rest

In short: Transport encryption protects what travels; encryption at rest protects what is stored. They answer different threats and neither replaces the other.

HTTPS encrypts the exchange between browser and server: without it, everything crossing a shared network is readable. It is now a prerequisite rather than an option, and certificates renew automatically, which removed the excuses of cost and forgotten expiry.

Encryption at rest protects something else: what remains on a disk, a backup or a database snapshot. It addresses the case where someone obtains the physical medium or a copy of the storage. It does not, however, protect against a compromised account that is entitled to read that data — that is the job of access control, not encryption.

Access: proving who you are, and getting only what follows

In short: Authentication establishes an identity; authorisation decides what that identity may do. The second is neglected more than the first, and its flaws cost more.

A password alone is a single factor: whoever obtains it becomes the user. Multi-factor authentication adds an element the attacker must obtain separately, which makes phishing markedly less profitable. On accounts that administer a site, it is the measure with the best ratio of effort to effect.

Authorisation asks a different question: once logged in, what can each account do? The useful principle is least privilege — an account receives only the rights its task requires, and loses them when the task ends. The incidents that take longest to contain often come from accounts that could do more than their actual use demanded.

Session tokens deserve the same attention as passwords: short validity, revocability, rotation. A token that never expires is a permanent password its holder cannot change.

The exposed surface: forms, APIs and headers

In short: Anything a visitor can send is untrusted input. The rule fits in one sentence: validate on the server, escape on output, limit the rate.

Validation done only in the browser protects nothing: it improves the typing experience, but an attacker does not use the browser. The validation that counts is the server's, expressed by an explicit schema describing what is accepted rather than what is refused — a refusal list always forgets a case.

Escaping addresses another problem: content sent by one visitor and displayed as-is can execute code for the next. The rule is to escape at display time, according to context, and never to trust a cleanup performed on input.

Rate limiting and honeypot fields answer automated submissions. They do not stop a determined attacker, and that should be known: they remove the background noise, which is enough for a contact form and not enough for a login page, which also needs progressive lockout.

Security response headers complete the set by telling the browser what to refuse: which script sources to accept, who may display the site in a frame, whether to guess a file's type. They are checked against the server's actual response, never against the configuration.

Data: retention, backups and obligations

In short: The best-protected data is the data never collected. Then come retention periods, tested restores, and the obligations of the applicable framework.

Minimisation is the most effective and least costly measure: every field collected is a field to protect, keep, delete and justify. Before securing a piece of data, it is worth checking that it serves a purpose at all.

A backup that has never been restored is a hypothesis, not a guarantee. What can be verified is the restore: how long it takes, what it loses, and who knows how to run it. A backup reachable from the system it protects also offers little help against ransomware.

Obligations exist regarding personal data — informing people, retention periods, rights of access and deletion. Their exact content depends on the framework applicable to the organisation and should be confirmed by a qualified professional; what belongs to the project is making those obligations technically achievable rather than discovering them afterwards.

What technical security does not solve

In short: The measures described here protect a system. They protect neither against an organisation that works around them, nor a compromised supplier, nor a design error.

Most intrusions exploit no software flaw: they borrow a legitimate access obtained by phishing or password reuse. No HTTP header prevents that. What prevents it is a second factor, and people who know what an attempt looks like.

A project depends on libraries it does not write and services it does not host. Watching those dependencies and knowing how to update them is part of the work; believing the surface stops at bespoke code is a misjudgement.

Finally, security does not make up for a design error. If a piece of data should never have been collected, encrypting it only moves the problem. The first question is not how to protect that data, but whether it should exist.