Shieldome SiegeShieldome Siege
Methodology

Black Box vs White Box vs Gray Box Testing

Before an engagement starts, one of the first decisions to make is how much information the tester begins with. That choice has a name, and it shapes the entire test.

Black box: starting with nothing but a target

A black box test gives the tester no internal knowledge: no source code, no architecture diagrams, no credentials beyond what a real outside attacker could plausibly obtain themselves. It most closely simulates an external attacker with no inside help, at the cost of spending real engagement time on reconnaissance that internal staff could have shortcut in minutes.

White box: full visibility from the start

A white box test, sometimes called a clear box or crystal box test, gives the tester source code, architecture documentation, and often credentials at multiple privilege levels. It trades realism for depth and speed, surfacing issues a black box approach would likely miss entirely within a fixed time budget, since the tester never has to spend hours discovering something that could have been handed over on day one.

Gray box: the practical middle ground

A gray box test sits between the two: partial knowledge, typically a standard user account and a general sense of the application's structure, without full source access. This is the most common real-world choice for web application testing specifically, because it approximates what an attacker with a compromised low-privilege account, or a malicious insider, could actually do.

Neither approach is more "real" than the other. Each simulates a different threat model. A black box test tells you what an outsider with zero access could achieve. A gray box or white box test tells you what happens once that outsider, or an insider, already has a foothold.

How to choose for your engagement

If your biggest concern is what a completely external, uncredentialed attacker could reach, black box is the right frame. If you are more concerned with what a compromised account or a malicious insider could do once inside, gray or white box will surface far more relevant findings per hour of testing time. Many organizations run black box tests less frequently and gray box tests as their regular baseline for exactly this reason.

Whichever approach you choose, the same fundamentals still apply: everything still needs to stay inside a clearly defined Rules of Engagement, regardless of how much the tester already knows going in.

See it in an actual tool

Shieldome Siege enforces scope on every action and gates exploit confirmation behind a human approval, with a tamper-evident audit log of the whole engagement.

Read the documentation