The Digerati

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. Modern tooling, Claude included, can hand anyone a pile of candidate findings. The job is deciding which are real, which are exploitable in your product, and what fix will not break it, and that judgement comes from twenty years of building the systems under review. Because I am a working engineer rather than an audit firm, the output is fixes you can merge rather than a backlog. 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
  • Tools sweep for breadth; twenty years of building these systems decides what is real and what matters
  • 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.

What is not there

Tools flag the code you have. Experience flags what is missing: the absent rate limit, the missing audit trail, the gate that only exists client-side.

Worked examples

Three problems and how they were solved.

All three from systems I worked on from the inside. 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, which is 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, which is 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, and it is the bar this page has to clear itself.

AI features widen the attack surface

A product I worked on serves HTML generated by a language model back to logged-in users: untrusted markup inside an authenticated app, 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, then prompt injection, untrusted output and what your tools can be talked into exfiltrating are now part of review scope, and it is 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, and the two 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, raised as pull requests where you want them, plus 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.

Could we not just run Claude over our codebase ourselves?

You could, and you should; I will even wire it into your CI as part of the engagement. What the tools produce is candidates. Turning candidates into a short list of real, exploitable, prioritised issues with fixes that suit your codebase is engineering judgement, and misjudging it cuts both ways: teams drown a real vulnerability in plausible noise, or dismiss the one finding that mattered. The sweep is the cheap part. Knowing what to ignore, and what to lose sleep over, is what you are hiring.

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 the stack, the rough size and 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.