What's the actual difference between black-box, grey-box, and white-box penetration testing?

It's the starting knowledge and access the tester is given before testing begins — nothing beyond a public URL for black-box, a low-privileged authenticated account for grey-box, and source code plus architecture documentation for white-box. It has nothing to do with how skilled the tester is or how the report is written; only with what door they start behind.

Which box color should an online casino request?

Not one — a mix, mapped to the asset. The public-facing perimeter and lobby should be tested black-box to simulate a real unauthenticated attacker. The cashier, bonus engine, and player account flows need grey-box access, because most of the risk lives behind login. Any custom-built component — a proprietary game engine, an in-house RNG, a bespoke KYC pipeline — needs white-box review, because external probing can't substitute for reading code you own.

Does white-box testing mean handing over our entire codebase?

No — white-box scope is named per-component, the same as any other scope decision. You'd typically name the custom-built systems you own outright (game logic, RNG, internal tooling) and leave third-party or vendor-licensed components — a game provider's platform, a payment processor's SDK — out of white-box scope, because you can't legally hand over code you don't own.

Is grey-box pentesting the same thing as an authenticated vulnerability assessment?

No. Both start from a logged-in account, but they're different engagements. A vulnerability assessment is broad, recurring, and partly automated — built to cover a large or fast-changing estate on a cadence. A grey-box penetration test is deep, manual, and time-boxed — built to chain findings the way an attacker with a stolen account actually would. See vulnerability assessment vs penetration testing for iGaming for the fuller comparison.

Does the box color change how long the engagement takes?

It changes where the time goes, not necessarily the total. Black-box spends more of the window on reconnaissance and access discovery before exploitation can start. Grey-box and white-box skip most of that and spend the saved time going deeper into business logic and code paths — which is usually the better trade for a casino, where the highest-risk findings live past the login screen, not in front of it.

Black-box vs grey-box vs white-box pentest

The short answer

Black-box, grey-box, and white-box describe how much a penetration tester knows about your systems before testing starts — nothing beyond a public URL, a low-privileged authenticated account, or full source and architecture access. There's no single right answer for an online casino: the public perimeter is best tested black-box to simulate a real attacker, the cashier and bonus engine need grey-box access to reach the logic that actually carries financial risk, and any custom-built component needs white-box review because no amount of external probing substitutes for reading the code.

Who this is for

This is written for whoever is putting together a penetration testing RFP or renewal for an online casino or sportsbook — a CISO, Head of Security, or platform owner who already knows they need a penetration test but hasn't yet decided what to tell the tester going in. It assumes you've already settled the questions covered in scoping a penetration test for an online casino — which layers, which assets, which tier — and are now on the next decision: how much access and knowledge to grant, and why that answer isn't the same for every system you're testing.

It's not for you if the decision you're actually facing is manual versus automated testing — that's a different axis, covered in why we still do pure-manual penetration testing — or if what you need is broad, recurring coverage rather than a scoped test, which is the job of a vulnerability assessment.

What each level actually means

The three terms describe a spectrum of starting access, not three unrelated products:

Black-box — the tester starts with nothing beyond what's publicly discoverable: your domain, your app store listing, whatever a real unauthenticated visitor or attacker would see. No credentials, no architecture diagrams, no internal documentation. This is the closest simulation of an opportunistic external attacker, and it's the only approach that genuinely tests your reconnaissance-resistance — whether an attacker can even find the cashier API or the affiliate portal without being told where to look.
Grey-box — the tester starts with partial knowledge, typically a standard low-privileged account (a player account, a support-tier back-office login) and enough documentation to understand intended behavior. This is where most of the engagement time for a casino should go, because it's the access level of the attacker who actually matters most: the one who has stolen or purchased a valid session, a leaked credential pair, or a low-tier affiliate login, and is now trying to escalate.
White-box — the tester has source code, architecture documentation, and often a working local build. This is the only level that reliably finds logic flaws buried in code that never surfaces in HTTP traffic — a race condition in how your RNG seeds a shuffle, a rounding error in how your bonus engine calculates wagering requirements, an authorization check that exists in one code path and was forgotten in a near-identical one three files over.

None of these is more "manual" or less rigorous than the others — all three are still 100% hand-tested by a senior engineer, the same standard covered in why we still do pure-manual penetration testing. The variable is only what the engineer is allowed to see before they start.

The decision matrix

Dimension	Black-box	Grey-box	White-box
Starting access	None — public information only	A standard low-privileged account	Source code + architecture docs
Best simulates	An opportunistic external attacker	A stolen credential or leaked session	An insider, or a determined attacker who already breached the perimeter
Where the test time goes	Reconnaissance and access discovery, then exploitation	Mostly exploitation and business-logic chaining	Code review plus exploitation of what the review surfaces
Casino risk it targets best	Perimeter exposure, forgotten subdomains, public API abuse	Cashier, bonus engine, session handling — where most real fraud actually happens	Game logic, RNG integrity, custom KYC/AML pipelines
What it can't tell you	Whether an authenticated attacker can escalate — because the tester never gets that far in the window	Whether a bug exists in code paths no request ever exercises	Whether the flaw is realistically reachable by an external attacker without insider access

Mapping box color to what a casino actually runs

A single-color engagement against an entire casino platform is how operators end up with a report that either misses the risk or wastes budget re-proving the obvious. Splitting the scope by system is what actually matches spend to risk:

Public perimeter and lobby — black-box. Marketing site, game lobby, public API endpoints, and anything a logged-out visitor can reach. The interesting question here is discoverability and exposure, not logic, so unauthenticated access is the right simulation.
Cashier, bonus engine, player session handling — grey-box. This is where credential stuffing against casino cashiers already shows attackers arrive with a valid-looking session rather than none at all, and where the test-case matrix for cashier security testing is built around exactly that starting point. A grey-box tester with a real low-tier account can reach the deposit/withdrawal flow, the bonus claim endpoint, and the session-transition logic that a black-box tester might never authenticate into within the testing window.
Custom game engine, in-house RNG, bespoke back-office tooling — white-box. If you built it, source review is the only way to catch a flaw that never produces an anomalous HTTP request — a shuffle algorithm with a statistical bias, a wagering-requirement calculation that rounds in the player's favor under a specific currency conversion. Third-party or vendor-licensed game providers stay out of white-box scope by default, because you can't hand over code you don't own; those get tested black-box or grey-box against their public and authenticated interfaces instead.
KYC/AML back-office panel — grey-box, sometimes white-box. Internal-facing and rarely load-tested by anyone, this is a strong grey-box candidate at minimum (a compromised support-tier account is a realistic attacker starting point), and a white-box candidate if the KYC decisioning logic is built in-house rather than bought from a vendor.

What you walk away with

The deliverable is the same regardless of which box color produced the finding: an executive summary in business-risk language, a technical report with reproduction steps a developer can follow, per-finding remediation guidance, and a retest against the exact technique that found the issue — the full breakdown is in what a real pentest report looks like. What differs is the finding mix. A black-box-only report tends to be perimeter-heavy; a grey-box-heavy report surfaces more business-logic and authorization findings; a white-box component adds findings that never would have shown up in traffic at all. A report that mixes all three, mapped to the systems above, is the one that actually reflects your real risk rather than whichever attacker profile happened to get simulated.

Limitations — what box color doesn't fix

Box color changes what a tester can reach, not what they're guaranteed to find in a fixed window — a black-box test that never authenticates within the engagement window tells you nothing about post-login risk, and a white-box review that only covers the components you named tells you nothing about the vendor code you excluded. It's also not a substitute for deciding scope and RoE in the first place; box color is one input into the scoping decision, not a replacement for it. And it doesn't replace ongoing coverage between engagements — a clean report this quarter says nothing about what shipped last week, which is what a managed SOC is for.

How to decide

Start from the asset, not from a preference for one methodology. List the systems that carry real financial or regulatory risk — cashier, bonus engine, KYC, anything custom-built — and assign each one the access level that matches how a real attacker would actually reach it: nothing for the public perimeter, a stolen-credential-equivalent account for anything behind login, source access for anything you built and nobody outside your team can otherwise inspect. If you can't yet map your own systems to that list, that gap is the starting point for the scoping call, not a reason to default to whichever box color sounds most thorough. Tell us your platform and we'll turn it into a scope that mixes access levels by system, not a single color applied uniformly.

Sources and review

The black-box/grey-box/white-box framework reflects standard industry penetration-testing terminology, applied here to AnySec's own engagement methodology and scoping practice. No third-party benchmark or vendor claim is cited as fact. Author: AnySec Engineering. Published 2026-08-15; last reviewed 2026-08-15.