Grey Box Test · Customer Story

When the perimeter looks fine,
what's behind it?

The team behind a fast-growing Australian consumer subscription platform had done most things right. Cloudflare in front. HSTS preloaded. CSRF on the login form. KYC for age verification. Modern Next.js stack on AWS. The kind of setup most founders sleep well over.

They asked us to run a grey-box test against their production app - credentials in, scanner running, the next day: a report.

The headline finding was one nobody had spotted.

A public profile lookup endpoint - the kind every social platform exposes for usernames - was returning the full user record without authentication. For most users that meant exposed avatars and bios. For the admin account, it meant the response included role: admin and the database id: 1.

An attacker could enumerate which accounts were administrators and target them directly with credential stuffing or password-reset abuse. Combined with username enumeration (also flagged in the report), it was a clean privilege-mapping vector.

It wasn't an architecture problem. It wasn't a missing WAF rule. It was a public DTO that hadn't been trimmed properly - fifteen lines of code, deployed eighteen months earlier, never noticed because every internal review had focused on whether the auth middleware worked, not on whether the public endpoint needed auth at all.

The team patched it the next morning. Total elapsed time from "scan started" to "production hotfix shipped": under 24 hours.

What else came back

The same report flagged three other things worth a sprint of attention:

  • The Content-Security-Policy was set to Report-Only - meaning XSS attempts would be logged but not blocked.
  • A development banking endpoint was listed in the production CSP's form-action directive - meaning prod-customer payment forms were authorised to submit to dev infrastructure.
  • Authentication errors used inconsistent HTTP status codes (401 in some places, 404 in others). Minor on its own; combined with public profile lookups, a username enumeration vector.

None of these were dramatic. All of them were fixable. Each came with a specific remediation step and a link to the canonical reference.

What the report also said -
and this matters.

A pen test report that only lists problems isn't useful. It's stressful, and it doesn't tell anyone what to keep doing.

So the report led with what was working:

HSTS configured properly with preload + includeSubDomains
CSRF protection actively rejecting requests without an Origin header
CORS strictly limited to the production domain - verified against spoofed Origin headers
No hardcoded secrets in any of the 424KB of client JavaScript the scanner mined
.env, .git/config, .DS_Store all blocked at the edge
CDN + WAF correctly classifying traffic

The platform's cyber posture was, on balance, strong - and the team needed to hear that as much as they needed the list of fixes.

Why this engagement worked

Two things, really.

It was fast enough to act on.

The team got the report on the same day they ordered the test. Not in three weeks, not after two scoping calls. By the time the developer who'd written the original profile endpoint sat down with their morning coffee, the fix was already on the board.

It was thorough enough to trust.

The scan crawled the authenticated app, mined the JavaScript bundles for endpoint maps, force-browsed for sensitive paths, classified every IP by ownership so CDN infrastructure wasn't reported as the customer's, and ran each finding through two independent AI models for cross-validation.

One day. One critical fix. Three medium issues prioritised for the next sprint. A clear list of things the team didn't need to worry about.

That was the engagement.

Curious what we'd find on yours?

Same scanner. Same report quality. From $1,550 ex GST.