Service
Application security engineering
A build decision, not a phase before launch.
For teams who need security to be a property of the software rather than a report about it. We work on the parts that are expensive to retrofit - authorisation, session handling, secret management, dependency risk - and prove them with tests that try to break the system.
The decision
When this is the right call.
Security that arrives as a scan two weeks before launch finds the cheap things and misses the expensive ones. Missing headers and outdated libraries are real but shallow. Broken access control - a user reaching another tenant's record by changing an identifier - is the most common serious flaw in business software, and no scanner reliably finds it because it looks exactly like a legitimate request.
That class of flaw is an architecture problem. If authorisation is enforced by hiding menu items, or by a check that some routes remember to call, then the question is not whether there is a hole but where. Retrofitting a consistent model into a finished application is one of the most expensive changes there is.
So we make it a build decision: every request authorised on the server against the acting user, tests that deliberately request another tenant's data and assert a refusal, and secrets that were never in the repository in the first place.
What you get
What the work covers.
Authorisation by default
Every endpoint authorised server-side against the acting user, with denial as the default rather than the exception.
Tests that attack
Automated tests that request another tenant's records, escalate roles and replay expired tokens, asserting each is refused. These run on every commit.
Session and token handling
Expiry, refresh and revocation designed properly, so an expired session ends cleanly instead of retrying forever.
Secrets management
Credentials out of the repository and out of config files, rotatable without a redeploy, with a documented rotation procedure.
Dependency and supply chain
Automated dependency review with a policy for what blocks a release, plus lockfiles and reproducible builds.
Transport and headers
TLS configuration, HSTS, CSP and the rest set at the origin and verified, including the protocol-level settings that quietly break clients.
Stack
What we build it with.
Chosen per project. Nothing here is applied by default, and the team who will maintain it counts as much as the problem.
Review
Threat modelling on the data and the roles, before the design is fixed.
Testing
Authorisation tests in CI, dependency scanning on every build, and periodic manual review of the paths that matter.
Infrastructure
Least-privilege service accounts, network boundaries, and backups with a restore that has actually been rehearsed.
Monitoring
Authentication failures, authorisation denials and error rates alerted on, because an attempt is a signal worth having.
Response
A written procedure for the day something goes wrong, agreed before it does.
Comparison
A scan before launch vs security as a build decision.
Scanners are worth running and find real things. They do not find the class of flaw that actually costs businesses money.
| Aspect | Scan before launch | Built in |
|---|---|---|
| Broken access control | Largely missed - a request for another tenant's record looks identical to a legitimate one | Tests that deliberately request another tenant's data and assert a refusal, on every commit |
| Outdated dependencies | Found, which is genuinely useful | Found earlier, with a policy for what blocks a release |
| Missing headers and TLS settings | Found | Set at the origin and verified, including the protocol-level settings that quietly break clients |
| Secrets in the repository | Found once they are already in the history | Never committed, and rotatable without a redeploy |
| When problems surface | Two weeks before launch, when the architecture is fixed | While the design is still cheap to change |
| Cost of the fix | A permission model reworked after launch costs weeks plus a migration | Days at the start, then close to nothing |
How it runs
From first conversation to live.
Indicative for work of this shape. The pilot is not optional — nothing is switched over until the people using it say it holds.
- 3-5 days
Threat model
The data, the roles and what an attacker would actually want, before the design is fixed.
- 2-3 weeks
Foundations
Server-side authorisation on every endpoint, session and token handling, secrets out of the repository with a documented rotation.
- 1-2 weeks
Adversarial tests
Automated tests that cross tenants, escalate roles and replay expired tokens, wired into CI so a regression fails the build.
- continuous
Ongoing
Dependency policy, alerting on authorisation denials, and a written response procedure agreed before it is needed.
After launch
What changes.
- The most common serious flaw in business software is covered by tests rather than by hope.
- An expired session ends cleanly instead of retrying a dead request until something gives up.
- A leaked credential is a rotation, not a redeploy and an incident.
- A penetration test comes back short, because the expensive findings were designed out.
Described qualitatively on purpose. We do not publish percentage improvements we cannot attribute to a named client with their agreement.
Questions
Common questions.
Is this a penetration test?
No. A penetration test is a point-in-time assessment by an independent party, and you should commission one separately - we can help you scope it. This is the engineering that makes the test come back short, and it continues after the test is filed.
We already have a scanner. Is that not enough?
Scanners are worth running and they find real things, but they mostly find known-vulnerable dependencies and missing headers. Broken access control, the most common serious flaw in business software, looks like a valid request and needs tests written against your own permission model.
Can you review an application we already have?
Yes. A review of an existing codebase typically takes one to two weeks and produces a prioritised list with the reasoning, not a raw scanner export. We can implement the fixes or hand them to your team.
Does this slow the build down?
Marginally at the start and considerably less than retrofitting later. Authorisation tests and dependency policy add days at the beginning; a permission model reworked after launch costs weeks and a migration.
We are a small team. Is this proportionate?
The authorisation work is, because it is cheap at the start and very expensive later, and it is the flaw most likely to expose one customer's data to another. Full threat modelling and continuous monitoring can wait until there is something worth monitoring.
Do you handle compliance certifications?
We do the engineering that makes an audit straightforward - access control, audit trails, encryption, retention, documented procedures - but we are not auditors and do not issue certifications. Where a specific framework applies, bring the auditor in early and we will build to what they actually require.