Security by design: why a check at the end of a project arrives too late

A security flaw found during design costs a conversation. The same flaw found after launch costs a rewrite and a notification to customers. The difference is not in the flaw, but in when it surfaced.

The usual sequence runs like this: the project gets built, somebody orders an audit a week before launch, the audit finds authorisation is checked in the wrong place — and fixing it means touching half the application. The date is already running, so the finding is "logged for later". Later does not come.

What "security by design" means

Not more documents. One extra step before a feature is written: go through what could be abused, and turn each answer into a concrete requirement.

For an ordinary application this fits into fifteen minutes, and the questions are always similar:

• Who is allowed to do this? And is it checked on the server, or is a button merely hidden?
• What if someone edits the ID in the URL? Do they see somebody else's data, or get refused?
• What if they send a different amount than the one on screen? Does the client's number decide, or does the server compute its own?
• What if they run it a thousand times a minute? And what if they run it twice at once?
• What reaches the log? Does a password, a token or full personal data end up in it?

A threat has to become a test

This is the difference between security by design and security in a slide deck. A measure that exists only as a sentence in a document disappears at the first refactor and nobody notices.

So every answer should end in a test: a test that an unauthorised user is refused; a test that someone else's ID returns an error rather than data; a test that an amount sent by the client is ignored. When somebody removes that check by accident six months later, the build fails — not the customer.

Three things that fail most often in practice

They are not exotic attacks. They are three ordinary ones:

• Authorisation at the wrong layer. The interface hides a button while the endpoint stays open. Hiding something in the UI is not access control.
• Trusting input from the client. Price, discount, quantity or the sender's identity arrive from the browser and the server takes them at face value. Anything from a client is a proposal, not a fact.
• Secrets and personal data in logs. The whole request gets logged "just in case", token included. That log is then copied to places where the same rules do not apply.

When NIS2 and GDPR are the reason

Some companies start caring about security because of regulation. That is a legitimate reason, and it overlaps technically with what is sensible anyway: knowing where which data sits, who can reach it, and keeping a record of what happened to it.

What you will not get from us is an assessment of whether a particular obligation applies to you and to what extent. That belongs with your lawyer — we prepare the technical groundwork and the measures, not the legal reading.

An audit makes sense, just not as the first step

We do review finished solutions independently, and it is worth doing — when taking a system over from another supplier, ahead of a larger launch, or when the operator changes. We go through authentication, authorisation, input handling, dependencies and configuration, and you get findings ranked by real impact with a suggested fix.

It is simply not a substitute for the first step. An audit tells you what is wrong. Security by design keeps the list short.

How we do it

We work through threats for every feature, endpoint and data model, and they become acceptance criteria that turn into tests. Data is encrypted in transit and at rest, access is granted by role, and sensitive operations are written to a separate audit trail that cannot be rewritten from inside the application.

If you are taking over somebody else's system, or about to launch something where a leak would hurt, write to us. More about this area is on our services page.