Modernisation & Consulting

Application Security

Finding it before someone else does.

Most breaches in business applications do not involve novel techniques. They involve an endpoint that checks authentication but not authorisation, a file upload that trusts the extension, a dependency three years out of date, or a credential committed to a repository years ago and never rotated.

Those are all findable, and finding them is considerably cheaper than the alternative. We review applications for the failures that actually occur, fix what is found, and put in place the controls that stop the same class of problem returning.

This is defensive work on systems you own or are authorised to test. It covers review, remediation and the ongoing practices — dependency monitoring, secret scanning, security-relevant tests — that keep an application defensible as it changes.

At a glance

Typical stack: Laravel PHP AWS Docker
Common industries: Healthcare, Finance
Engagement: Fixed scope, dedicated team, or staff augmentation

Request a quote

No obligation. We will tell you if it is not a fit.

The problem

What this solves

The most common serious defect is broken access control: an endpoint that verifies who you are but not whether this particular record is yours. It is invisible in the interface, because the interface only ever shows you your own records, and it is trivially exploitable by changing an identifier in a request.

The second is time. An application secure at launch drifts: dependencies age out of support, new endpoints are added without the same scrutiny, and credentials accumulate in places nobody is watching. Security assessed once and never again describes a state that no longer exists.

Authorisation missing on endpoints

Authentication is checked, ownership is not, and changing an id in a request returns someone else's data.
Uploads trusted by extension

A file renamed to .png is accepted and served back from your own origin.
Dependencies out of support

Known vulnerabilities with published exploits sitting in the lock file.
Secrets in the repository

Credentials committed at some point in history and never rotated since.

Our approach

How we go about it

We review against how applications actually fail rather than against a generic checklist: authorisation on every path, input handling and output encoding, file upload treatment, authentication and session behaviour, secret management, dependency currency, and what the application discloses in errors and logs.

Findings come with a working demonstration and a specific remediation, not a category name. "Broken access control" is not actionable; "this endpoint returns any invoice by id without checking ownership, here is the request, here is the fix" is.

Then we make the class of problem hard to reintroduce: authorisation tests that fail the build if a path is unprotected, dependency and secret scanning in the pipeline, and sensible defaults so the next developer has to work to get it wrong.

Capabilities

What is included

Application security code review
Authentication and authorisation audit
Dependency and supply-chain review
Secure file upload and storage review
Security header and configuration hardening
Remediation support and re-testing

Outcomes

What changes for you

Findings you can act on

Each one demonstrated with a real request and a specific fix, not a category label.
Regression tests for access control

Authorisation covered by tests, so an unprotected new endpoint fails the build.
Automated dependency and secret scanning

The pipeline notices an aging dependency or a committed credential before a person has to.
Safe defaults

The framework configured so the insecure option requires deliberate effort.

Related work

Where we have done this

All case studies

SaaS & Startups

SecureShare — Encrypted File Transfer

A secure file transfer platform: files are encrypted with AES-256 through upload, storage and download, shared over unguessable links with optional passwords, and deleted automatically when they expire.
- Laravel
- PHP
- Tailwind CSS
- +2
View case study

Frequently asked questions

Common questions about application security.

Is this a penetration test?

It overlaps but it is not the same thing. A penetration test is time-boxed adversarial testing, usually for a compliance requirement, and produces a report. This is review plus remediation plus the controls that stop recurrence — we fix what we find and make the class of problem harder to reintroduce. Both are useful; a formal pen test from an accredited assessor is what you want if a certification requires one.

How often should an application be reviewed?

Reviewing on a calendar matters less than having continuous controls. Dependency and secret scanning running on every build catches the majority of drift automatically. A deeper review is worth doing after significant architectural change, before handling a materially more sensitive class of data, or when a customer requires evidence.

Do you need access to our source code?

It makes the review far more effective. Reading the authorisation logic finds missing checks that black-box testing would only find by guessing the right request. We work under whatever access and confidentiality arrangement you need, and we only test systems you own or have written authorisation to test.

Related services

When was your access control last actually tested?

Not authentication — authorisation. It is the most common serious defect and the least visible.

Start a project Talk to our team