What makes a crypto exchange vulnerability assessment different from a web application scan?

The assets that matter most are not only web pages. They are the trading and market-data APIs, the withdrawal and deposit pipeline, blockchain node and RPC endpoints, admin and operations consoles, and the custody and KYC vendors you integrate with. The assessment has to start from an inventory of those, not from the marketing domain.

Should the assessment touch the wallets or signing infrastructure themselves?

Only with explicit scope, rules of engagement and a safe environment. A vulnerability assessment normally checks exposed services and configuration from the outside and, with test accounts, from the inside. Anything that can move funds belongs in a separate, deliberately scoped exercise, ideally against a staging replica.

Do we need a custody or KYC vendor's permission to scan their endpoints?

Yes for anything the vendor owns or hosts. Assess your own integration instead: how API keys are stored and rotated, how callbacks are authenticated, and what happens when the vendor's response is wrong or late. Check each vendor's testing policy before scanning anything they run.

What should we have ready before asking for a quote?

Public hostnames and IP ranges, the list of API hosts and versions you expose, every node or RPC endpoint reachable from outside, admin consoles and who can reach them, inbound callback and webhook URLs, and the vendors on the deposit, withdrawal and onboarding path. A responder can only assess what the inventory names.

How is this different from the cadence question?

Cadence asks how often to run an assessment. Scope asks what it covers. This article is about scope; see the separate guidance on how often a crypto exchange should run one.

Vulnerability Assessment for a Crypto Exchange: Scoping the Withdrawal Pipeline, Trading APIs, and Custody Vendors

The short answer

A crypto exchange's most valuable exposed surface is not the website. It is the set of systems that accept orders, publish prices, move deposits and withdrawals, talk to blockchain nodes and hand customer identity checks to vendors. A vulnerability assessment is only as good as the inventory it starts from, so list those systems first, mark which ones you own, which you control at an integration seam and which a vendor owns, and scope the assessment around the first two. Anything that can move funds should be scoped as its own exercise, not folded into a routine scan.

Who this is for

This is for a CISO, head of platform or engineering lead at a crypto exchange or trading venue who has scanned the main domain and the web application, and suspects the API, node and operations estate behind it was never fully in scope. For the question of how often to run one, see how often a crypto exchange should run a vulnerability assessment. This article is about what the assessment should cover.

Where an exchange's surface actually lives

Start from what a trader, a market-data consumer and an operations engineer can each reach, and write down every host.

Surface	Why it matters	Who owns the fix
Trading APIs (REST, WebSocket, FIX-style gateways)	Order entry and account actions, often several versions live at once	You
Market-data and public price feeds	High-volume public endpoints that share infrastructure with the rest	You
Deposit and withdrawal pipeline	Public callbacks, queues and approval services around moving funds	You
Blockchain node and RPC endpoints	Exposed ports and admin interfaces are common misconfigurations	You, or the node provider
Admin, support and operations consoles	Should not be reachable from the public internet	You
KYC, custody and payment vendor integrations	Callbacks, API keys and trust in vendor responses	Shared: vendor operates, you validate
Mobile app backends and legacy API versions	Older hosts are where forgotten exposure collects	You

Build the inventory before the quote

A scanner can only test what it is pointed at. Before you ask anyone for a quote, assemble:

Hostnames and IP ranges, including staging, sandbox and regional hosts. Certificate transparency logs and DNS records often reveal hosts the team has forgotten.
API hosts and versions, including deprecated ones that still answer.
Node and RPC endpoints reachable from outside, with the provider that runs each.
Inbound endpoints: deposit notifications, vendor callbacks, webhooks and anything a partner calls.
Operations and admin interfaces, with a note on who can reach each and from where.
Vendors on the money and onboarding path: custody, KYC, payments, market makers.
Ownership: for each item, who can fix it.

The same discipline applies in adjacent verticals; see how it works for a Web3 front end in vulnerability assessment for a DeFi protocol.

What to scope in

Scope in what you own and what you control at the seam:

Your hosts and exposed services, scanned from outside, with authenticated checks where you can provide test accounts at several privilege levels.
Your API surface, including old versions, error handling and rate-limit behaviour, as far as a non-intrusive assessment can observe.
Your integration with each vendor: where keys are held, whether callbacks are authenticated, and how your systems behave when a vendor response is missing or malformed.
Node and RPC endpoints you run, checking that administrative interfaces are not exposed.

What to keep out of a routine assessment

Two categories need separate treatment.

Anything that can move funds. Signing services, withdrawal approval logic and wallet infrastructure should not be probed as a side effect of a routine scan. If they are in scope, define it explicitly, test against a staging replica where possible, and agree stop conditions in the rules of engagement. Testing the logic of a withdrawal flow is closer to a penetration test of a crypto exchange than to a scan.

Vendor-owned infrastructure. Weaknesses in a custody provider's or KYC vendor's hosted service are theirs to fix, and testing it without permission may breach their terms. Check each testing policy and ask in the contract for a way to receive and act on their findings. A scan result that lists a vendor-hosted issue should become a ticket to the vendor with an owner.

What the report must separate

Ask for findings grouped by ownership, so nothing is lost between teams:

Findings on assets you own, with severity and a fix.
Findings in your integration with a vendor, for example a callback endpoint that accepts unauthenticated input.
Items that belong to a vendor, with evidence you can pass on.

Then handle the output the way described in triaging vulnerability scan results: a short critical list, a fix queue and an owner for each line. Where the same inventory reveals hosts that should not be exposed at all, the follow-up is usually hardening rather than another scan.

Limitations

This article is not legal or regulatory advice and does not say what any regulator or licence requires of a crypto exchange. It names no statistics. A vulnerability assessment finds known weaknesses on the assets it is pointed at; it does not prove the absence of others, and it does not test business logic such as withdrawal approval rules. Vendor testing rules differ, so confirm them in each contract.

Decision and next step

If you can list every hostname, API version, node endpoint, callback URL and vendor on the funds path, and name an owner for each, you can scope an assessment properly. If not, that list is the first deliverable. Request an asset-scope quote and we will reply with a fixed quote and rules of engagement.

Sources and review

No external statistics or regulatory claims are used. Author: AnySec Engineering. Published 2026-10-30; last reviewed 2026-10-30.