Security code review · Singapore

Security code review in Singapore, available now

Most security review arrives as a PDF of findings someone else is supposed to fix. I review codebases the way they actually get breached — auth flows, payment paths, what leaks into the client payload — and because I am a working engineer rather than an audit firm, the output is fixes you can merge rather than a backlog. I use Claude to sweep a whole codebase for what a human reviewer skims past, then verify every finding by hand before you see it. Nothing goes in the report that I could not demonstrate.

Reviewed in the code, not the org chart: auth, sessions, payments, data exposure and secrets
AI-assisted sweeps with Claude for breadth, every finding verified by hand before it is reported
Findings arrive as prioritised fixes and pull requests, not a PDF and a handshake

See selected work

Availability and engagement

Straight answers to the things recruiters screen on first.

Available now Singapore, on-site or hybrid Full-time contract engagements Fixed-scope projects Day rate on request

Security

What a review actually covers.

Auth & sessions

Password storage, cookie scope, session fixation and login throttling, reviewed against how they fail rather than against a checklist.

Payment paths

Webhook signatures verified over the raw body, idempotent retries, and ledgers that can explain any balance after the fact.

Data exposure

What actually ships to the client: RSC payloads, over-fetched API responses, and paid content that is hidden rather than gated.

Untrusted content

XSS and injection, and when sanitising is the wrong answer — isolation by origin and sandbox instead of regex and hope.

Headers & CSP

Content-Security-Policy that pins real origins, nonce-based inline script and HSTS — this site sends all of it, so check the response headers.

AI-assisted review

Claude-driven sweeps across the whole codebase, tracing data flows between files — triaged and verified by hand, never pasted into a report.

Worked examples

Three problems and how they were solved.

Two from my own systems, one from inside a client’s team — ask me to go deeper on any of them.

An organisation tier added without an incident

A live B2B product needed organisations layered onto individual accounts — exactly the kind of change where authorisation bugs are born. Permissions are resolved once, when the token is minted, rather than re-derived in every handler, which removes a whole class of scattered, subtly different checks. The change shipped across 50 migrations with 274 Playwright tests holding the line, and no customer noticed the ground move. Security review is cheapest at this stage, while the design still has options — that is when to bring someone in.

The headers on the page you are reading

This site sends a content-security policy that pins every third-party origin it is allowed to load script from, with a stricter nonce-based policy running in report-only mode until the console is provably clean — the standard way to tighten CSP on a live site without breaking it. HSTS, frame-ancestors, referrer and permissions policies ride along. None of it is exotic. The point is that it is verifiable: open the network tab and read the response headers. That is the bar I hold a review to — claims you can check yourself.

AI features widen the attack surface

A product I built serves HTML generated by a language model back to logged-in users — untrusted markup inside an authenticated app, which is a breach waiting to be misconfigured. It ships behind three independent controls: a separate origin, a sandboxed frame with an opaque origin, and a session cookie scoped so it cannot travel there. Any one would do; three means one mistake is not an incident. If you are adding LLM features, prompt injection, untrusted output and what your tools can be talked into exfiltrating are now part of review scope — a part I build in daily.

FAQ

Security review in Singapore — common questions

Is this a penetration test?

No, and I will say so plainly rather than sell you one. A pentest probes the running system from outside; this is a review of code, configuration and architecture from inside — they find different bugs. If you need a certified pentest for compliance, I will tell you so, and a code review first tends to make the pentest report you pay for shorter.

What do I actually get?

A prioritised set of findings, each with evidence and a concrete fix — as pull requests where you want them — and a walkthrough of the lot rather than a PDF lobbed over the wall. What you will not get is a hundred pages of severity-tagged linter output.

Do you use AI tools like Claude in the review?

Yes, openly. Claude-assisted sweeps are good at breadth: tracing data flow across files no human reviewer would open in the same afternoon. Every finding is then verified by hand, because unverified scanner output is how real issues drown in noise. The report only contains what I could demonstrate.

Can you fix what you find?

Yes — that is rather the point of having a working engineer do the review. Findings can roll into a remediation contract, on-site or hybrid in Singapore, or a fixed-scope engagement through The Digerati. I would rather leave you with merged fixes than an impressive list.

How long does a review take?

A focused review of one service or product usually lands within one to two weeks, depending on size and scope. Tell me what you have — stack, rough size, what worries you — and you will get a straight estimate rather than a discovery phase.

Do you review AI and LLM features?

Yes, and increasingly that is why people get in touch: prompt injection, untrusted model output rendered into authenticated pages, retrieval that leaks documents across permission boundaries, and tools that can be persuaded to exfiltrate data. I build these systems as well as review them, which is the only honest way to keep up with how they break.