Web Application Pentesting for Crypto and Fintech

By the Guardian team Updated November 2026 6 min read

Quick answer. Everything in an OWASP web test, plus the flows that move money: login, withdrawals and allowlists, KYC, admin panels, signing screens, API keys, deposit webhooks and balance races. A generic test checks controls; this one attacks each flow.

Watch: Web Application Pentesting for Crypto and Fintech 1:43

Video transcript

A smart contract audit reads the contracts. It does not test the login page, withdrawal API or admin panel that decide who can move money.

A generic pentest confirms that controls like two factor authentication exist. A crypto or fintech test tries to defeat them, by skipping steps, replaying deposit events or racing withdrawals.

Two OWASP sources set the method. WSTG says how to test, and ASVS 5.0 says what passing means. Name the ASVS level in your statement of work.

Each money flow needs its own test cases: login and sessions, withdrawals and allowlists, KYC, admin panels, signing screens and API keys.

Take withdrawals. Testers call the final withdrawal endpoint without the two factor step, then add a new allowlist address and withdraw to it at once.

Deposit webhooks matter too. Stripe warns that without verification, an attacker could send fake webhook events. In Guardian's Synthetix review, a redelivered deposit event could inflate a user's collateral balance.

Black box starts with the URL only. Gray box adds accounts for every role. White box adds source code, so nothing user-reachable is missed.

Guardian's offchain practice is led by Carlos Polop, who co-founded HackTricks training. Guardian has secured over forty five billion dollars in digital assets and resolved over three hundred Critical vulnerabilities.

Read the full guide, or talk to Guardian about testing your web app.

A smart contract audit reads the contracts. It does not test the login page, the withdrawal API or the admin panel in front of them.

Those flows decide who can move money. A generic checklist confirms that controls exist; it does not always ask what a thief would do with each flow.

This guide maps eight crypto and fintech flows to two OWASP method sources.

The Method: WSTG and ASVS 5.0

The Web Security Testing Guide (WSTG) says how to test. Version 4.2 is the latest release, and OWASP is developing version 5.0.

The Application Security Verification Standard (ASVS) says what passing means. Version 5.0.0 was released in May 2025.

ASVS has three levels. It says most applications should aim for Level 2.

Its example for money: a bank "may have difficulty justifying anything less than Level 3" for online banking.

Name the ASVS level in the statement of work. Then every finding can be read against an agreed standard.

What Generic Pentests Miss

Each flow below needs its own test cases, beyond the generic checklist.

Flow	What to attack	Method reference
Login and session	Sign-in nonces, session binding, reset paths	WSTG 4.4, 4.6; ASVS V6, V7
Withdrawals and allowlists	Step order, re-authentication, new addresses	WSTG 4.10.6; ASVS 2.3.1, 7.5.1
KYC	Server-side status, document access, uploads	WSTG 4.10.8, 4.10.9; ASVS V5, 8.2.2
Admin panels	Discovery, role checks, step-up on fund moves	WSTG 4.2.5; ASVS 8.4.2, 7.5.3
Signing UIs	Scripts in the bundle; what users actually sign	WSTG 4.11; ASVS 3.4.3, 3.6.1
API keys	Scope, read-only limits, revocation	WSTG 4.5.3; ASVS 8.3.2
Webhooks and deposits	Forged, replayed, duplicate and reordered events	ASVS 4.1.5, 2.3.3
Balance races	Parallel requests against one balance	WSTG 4.10.5; ASVS 2.3.4, 15.4.2

Wallet login adds its own cases under Sign-In with Ethereum (EIP-4361).

Replay a captured sign-in message: a fresh nonce should stop it.
Check sessions are bound to the address, as EIP-4361 requires.
Confirm login issues a new session token (ASVS 7.2.4).
Try a password reset that skips MFA (ASVS 6.4.3).

Withdrawals and address allowlists

ASVS 2.3.1 asks that flows run "in the expected sequential step order and without skipping steps."

Call the final withdrawal endpoint without the 2FA step.
Add an allowlist address, then withdraw to it at once.
Change email or MFA without full re-authentication (ASVS 7.5.1).
Exceed limits that are enforced only on screen (ASVS 2.2.2).

At Level 3, ASVS 2.3.5 adds multi-user approval for high-value flows such as "large monetary transfers." For the full control set, see exchange withdrawal security.

KYC flows

Call KYC-gated actions directly: is status checked on the server (ASVS 8.3.1)?
Change a document ID to fetch another user's passport (WSTG 4.5.4, ASVS 8.2.2).
Upload unexpected and malicious files (WSTG 4.10.8 and 4.10.9).
Forge the KYC vendor's approval callback (see webhooks below).

Admin panels

WSTG 4.2.5 starts by finding admin interfaces. ASVS 8.4.2 asks for "multiple layers of security" on them, not network location alone.

In Guardian's Longshot review (M-18), a stolen admin session could call the admin withdraw route directly. No second factor stood in the way.

Test every admin action with a support-level role, then with a stolen admin session.

Signing UIs

A signing screen is only as safe as the code that renders it.

Find externally hosted scripts without Subresource Integrity (ASVS 3.6.1).
Check the Content Security Policy limits script sources (ASVS 3.4.3).
Test transaction pages for DOM-based XSS (WSTG 4.11.1).
Compare the amount and destination shown with the payload signed.

Our signing interface security guide covers the defenses.

API keys

OWASP's API Security Top 10 (2023) ranks broken object level authorization first. Sixth is unrestricted access to sensitive business flows.

Try to trade or withdraw with a read-only key (WSTG 4.5.3).
Revoke a key or cut its scope: does it apply at once (ASVS 8.3.2)?
Check IP allowlists hold, and keys never reach logs or bundles.

Webhooks and deposit crediting

Payment providers, KYC vendors and chain watchers tell your backend that something happened. If that message can be faked, balances can be faked.

Stripe's documentation puts it plainly: without verification, "an attacker could send fake webhook events" to trigger actions such as "granting account access."

Stripe also says endpoints "might occasionally receive the same event more than once," and it does not guarantee event order.

Send unsigned, re-signed and replayed callbacks (ASVS 4.1.5).
Deliver the same deposit event twice, then out of order.
Check each operation succeeds fully or rolls back (ASVS 2.3.3).

In Guardian's Synthetix withdrawal flow review (M-02), a deposit event redelivered after a restart could be applied again, "inflating the user's collateral balance."

Race conditions on balances

PortSwigger calls limit overruns "the most well-known type of race condition." They let a user exceed a limit the business logic sets.

Send parallel withdrawals, transfers and orders against one balance. ASVS asks for business-level locking (2.3.4) and atomic check-then-act (15.4.2).

Our crypto exchange pentesting guide lists more exchange test cases.

Black, Gray or White Box

Approach	Testers start with	Best for
Black box	The URL only	Seeing what an outsider sees
Gray box	Accounts for each role, API docs	Testing every role's flows
White box	All of that, plus source code	Proving every reachable function was tested

ASVS notes that even Level 1 is not necessarily testable by an outsider without documentation or code.

Guardian's web app pentest page calls the source repository "the only way to be certain nothing user-reachable was missed."

How to Scope and Prepare

Every role, with credentials: user, VIP, support, compliance and admin.
Funded test accounts on staging or testnet, with limits testers can hit.
The ASVS level you want verified.
API documentation, webhook endpoints and the providers behind them.
Sandbox access to your KYC and payment vendors.
Source repositories, for a white box test.
Rules of engagement: no mainnet value, no real customer data.
Retest rounds and dates, agreed before testing starts.

Our rules of engagement template has the clauses. For providers, see the best web application pentesting firms.

How Guardian Tests Web Apps

Guardian's offchain services are led by Carlos Polop, Head of Offchain Services. He co-founded and built HackTricks training into one of the most popular online cybersecurity training and certification sites.

Guardian's web app pentest maps every form, background request, socket and wallet interaction a user can reach, at every privilege level. Then it tests each one.

It covers authentication, authorization, value-moving flows, client-side surface, business logic and input handling. Frontend-only and backend-only scopes are available.

For fintechs, a trust center assembles audit and pentest outputs and retest status for partners, banks and auditors.

Across its engagements, Guardian has secured $45B+ in digital assets and reported and resolved 300+ Critical vulnerabilities.

Frequently Asked Questions

What does a web application pentest cover for a crypto company?

Everything in a standard web test, plus login and sessions, withdrawals and address allowlists, KYC, admin panels, signing screens, API keys, deposit webhooks and race conditions on balances. Each is attacked as a flow, not just checked as a control.

How is it different from a generic web pentest?

A generic test confirms that controls such as 2FA and access checks exist. A crypto or fintech test tries to defeat them in the flows that move value, for example by skipping steps, replaying deposit events or racing withdrawals.

Which OWASP standards apply to a fintech web app pentest?

The Web Security Testing Guide (WSTG) for how to test, and the Application Security Verification Standard (ASVS) 5.0 for what passing means. ASVS says a bank may struggle to justify anything below Level 3 for online banking.

Does a smart contract audit cover the web app?

No. An audit reviews contract code. The web app, its APIs and its admin tools need their own pentest, ideally by testers who can check findings against the contracts those systems call.

Sources

Test the flows that move your users' money

Guardian maps every function a user can reach, at every privilege level, and attacks the login, withdrawal, admin and API paths behind them.

Talk to Guardian Explore security for onchain teams