Code security review

An audit from the outside tests the visible doors. Reading the code means lifting the bonnet and spotting what hides inside: a forgotten secret, a poorly filtered input, a vulnerable dependency. FastSolve examines your code at the source, before an attacker finds the flaw there.

This service requires read access to your code and written authorisation. The code stays with you; nothing is kept or shared.

This service is billed on an accepted quote. An audit delivers findings, not a tool: the usual rule, test before paying, cannot apply here. The quote states in advance what it covers and how far the analysis goes.

What hides in the code

Some flaws leave no visible trace from the outside. They wait, written in plain text in the files, until someone gets their hands on them.

• A password, an access key or a token written straight into the code, sometimes copied unintentionally into a shared repository.
• A user input that reaches the database with no check, opening the way to an injection.
• An external component left on an old version, whose flaw is publicly known and documented.
• A snippet taken from a forum that works, but carries a known vulnerability with it.

These defects cannot be guessed from the home page. They are read, line by line, where they were written.

What the review covers

The reading targets the places where a coding mistake becomes a security flaw.

1. Secrets and configuration

We hunt for hardcoded credentials, keys and tokens, and check that the configuration properly separates what is public from what must stay hidden.

Typical case. An access key to a paid service sat in a file tracked by the repository. Taking it out of the code and replacing it closed a door no one had seen.

2. Input handling

We follow the path of user-sent data all the way to the database or the display, to ensure none of it runs where it should only be read.

Typical case. A database query was built by pasting the user's input directly. Rewriting it as a prepared statement removed the injection risk.

3. Access logic

We check that permission controls are on the server side, not merely hidden on screen, because what is hidden from the display remains reachable another way.

Typical case. An administration button was simply hidden for ordinary accounts, but the action stayed reachable by calling it directly. A server-side check restored the barrier.

4. Dependencies

We list external components and their versions, spot those with a known flaw, and indicate which to update first.

Typical case. An email-sending component was several versions behind, with a published flaw. Updating it took minutes, once the risk was identified.

What the review does not do

It sheds light on the code from a security angle. It does not rewrite your project or judge your technical choices.

• It does not replace the audit from the outside: the two views complement each other, one tests the doors, the other reads the locks.
• It does not rewrite your application. It points out the risky spots and how to fix them, the fix being separate work.
• It does not guarantee the absence of any flaw: no reading can. It sharply reduces what is known and avoidable.
• It needs access to the code. Without reading the sources, this service has no object, and the external audit is the right fit.

We hand you a clear list of what is worth fixing, without needless jargon and without dramatising what does not deserve it.

Frequently asked questions

Tell us which code you would like reviewed

See how a project unfolds, from scoping to delivery
See all FastSolve services