Digital asset platforms manage sensitive customer information, wallet addresses, transactions, payment integrations, and privileged administrative functions. A security weakness in any of these areas can affect account security, transaction accuracy, and the protection of digital assets. 

In this blog, we will discuss how a CERT-In Security Audit for Digital Asset Platforms can assess the security of wallet, transaction, and administrative workflows.  

What Should a CERT-In Security Audit Cover in a Digital Asset Platform? 

A CERT-In security audit for a digital asset platform should cover the applications, APIs, infrastructure, access controls, transaction workflows, and administrative functions that support the platform. The audit scope should match the systems and services used to manage digital assets, customer accounts, transactions, and platform operations. 

1. Digital Asset Wallets 

The audit should examine how wallets are created, accessed, managed, and linked to customer accounts. Testing should check whether one user can access another user’s wallet information or perform wallet actions without proper authorization. 

2. Deposit and Withdrawal Functions 

Deposit and withdrawal processes should be tested from request creation through completion. The assessment should check amount validation, user authorization, verification steps, transaction status changes, and controls that prevent unauthorized or repeated withdrawals. 

3. Asset Transfer Workflows 

Asset transfers should be reviewed to confirm that the sender, receiver, asset, amount, and transaction status are validated by the server. Testing should also check whether users can change transfer details after approval or bypass required workflow steps. 

4. Trading and Transaction APIs 

Trading and transaction APIs should be tested for authentication, authorization, parameter validation, access to transaction objects, rate controls, and sensitive information exposure. Each API that can create, modify, approve, or cancel a transaction should be included in the assessment. 

5. Customer Account Functions 

Customer functions such as profile changes, wallet access, authentication settings, withdrawal settings, and transaction history should be checked. The audit should verify that customers can access and modify only the information and functions assigned to their accounts. 

6. Administrative Functions 

Administrative functions should receive separate testing because they may provide access to multiple customer accounts, wallets, transactions, and platform settings. Testing should include admin login, role permissions, transaction approval, account management, wallet controls, and administrative APIs. 

7. Supporting Infrastructure and Cloud Services 

The audit should also consider the infrastructure supporting the platform, including cloud accounts, databases, storage, network services, identity systems, logging systems, and exposed management interfaces. Security controls should be reviewed across the components that support the digital asset application. 

How Should Digital Asset Wallet Security Be Tested? 

Wallet testing should focus on ownership, access control, wallet configuration, transaction permissions, and protection of wallet-related secrets. The assessment should verify that wallet operations cannot be changed or accessed by an unauthorized user. 

1. Wallet Creation and Address Generation 

Test whether wallet creation is correctly linked to the authenticated customer and whether wallet addresses are generated and assigned securely. Attempts to manipulate wallet identifiers or account references should be checked. 

2. Wallet Access Controls 

Test whether customers can access only their own wallet information and permitted wallet functions. API requests should also be checked because changing a wallet ID or account ID must not provide access to another customer’s wallet. 

3. Deposit Address Management 

Deposit addresses should be checked for correct customer and asset association. Testing should verify that a user cannot replace, reuse, or access another customer’s deposit address through application or API requests. 

4. Withdrawal Authorization 

Withdrawal requests should require the correct user authentication and authorization controls. Testing should check whether a withdrawal can be created, changed, approved, or submitted without completing the required security checks. 

5. Wallet Address Changes 

Changes to wallet addresses should be tested for authentication, authorization, verification, and transaction binding. The audit should check whether an attacker can change the destination address before a withdrawal is approved. 

6. Private Key and Secret Protection 

Private keys, seed information, API credentials, signing secrets, and other sensitive wallet data should be checked for proper storage and access restrictions. These values should not be unnecessarily exposed through application responses, logs, source code, or administrative interfaces. 

7. Wallet Activity Logging 

Wallet actions should generate suitable audit records so that important activity can be traced. Logs should help identify wallet creation, address changes, withdrawals, access attempts, administrative changes, and other sensitive actions. 

What Should Be Tested in Digital Asset Transactions? 

Transaction testing should verify that every important value and workflow state is checked on the server. OWASP guidance highlights the need to protect transaction data from modification and prevent users from skipping or changing transaction authorization steps. 

1. Transaction Amount Validation 

The server should calculate or validate transaction amounts rather than trusting values supplied by the client. Testing should include modified amounts, zero values, negative values, excessive values, decimal handling, and changes made between transaction steps. 

2. Source and Destination Validation 

The source account, wallet, destination address, asset type, and ownership relationship should be verified before a transaction is processed. Testing should check whether these values can be changed without proper authorization. 

3. Transaction Status Handling 

Transaction states such as pending, approved, rejected, completed, or cancelled should be controlled by the server. Testing should check whether a user can directly change a transaction from one state to another through API requests. 

4. Transaction ID Validation 

Transaction IDs should be checked against the authenticated user’s permissions and the requested operation. Changing a transaction ID in a request should not allow access to another customer’s transaction. 

5. Duplicate Transaction Prevention 

The platform should prevent the same transaction from being processed more than once. Testing should include repeated requests, retries, replayed requests, and concurrent requests against the same transaction. 

6. Transaction Limit Enforcement 

Daily, per-transaction, account-level, and asset-specific limits should be enforced on the server. Testing should check whether limits can be bypassed by changing request parameters, using multiple sessions, splitting transactions, or calling APIs directly. 

7. Transaction Confirmation Controls 

Confirmation steps should be linked to the exact transaction details being approved. Testing should check whether transaction data can be changed after confirmation or whether the confirmation process can be skipped. 

How Can Withdrawal Workflows Create Security Risks? 

Withdrawal workflows contain several security-sensitive steps because they can directly move digital assets from a customer’s account. Testing should examine every step from withdrawal creation to final processing. 

1. Unauthorized Withdrawal Requests 

Test whether an authenticated customer can create withdrawals for another account or whether an attacker can submit a withdrawal without the required authentication or verification. 

2. Withdrawal Amount Manipulation 

Test whether the withdrawal amount can be changed after the request is created or after approval. Server-side validation should ensure that the approved amount matches the amount that is finally processed. 

3. Destination Address Manipulation 

The destination address should remain tied to the approved withdrawal. Testing should check whether the address can be changed through a modified API request, browser request, or another workflow step. 

4. Bypassing Withdrawal Limits 

Test whether withdrawal limits can be avoided by changing account identifiers, asset values, request parameters, or transaction sequences. Controls should be applied on the server rather than relying only on the user interface. 

5. Reusing Approved Withdrawal Requests 

An approved withdrawal request should not be reusable when it is designed for one transaction. Testing should check whether an old approval token, request ID, or transaction reference can be replayed. 

6. Skipping Withdrawal Verification 

The audit should test whether required OTP, MFA, approval, address verification, or other security steps can be skipped by calling later workflow endpoints directly. 

7. Duplicate Withdrawal Processing 

Concurrent and repeated withdrawal requests should be tested to determine whether the same balance can be withdrawn more than once. Transaction processing should maintain a consistent account balance when multiple requests arrive close together. 

How Should Digital Asset APIs Be Tested? 

APIs often provide direct access to wallet, transaction, account, and administrative functions. OWASP identifies broken object authorization, broken authentication, broken function authorization, unrestricted resource consumption, sensitive business flows, and improper API inventory as major API security concerns. 

1. API Authentication 

Test whether sensitive APIs require valid authentication and whether expired, invalid, revoked, or altered tokens are rejected. Authentication controls should be consistent across web and API interfaces. 

2. API Authorization 

Authentication alone should not provide access to every function. Testing should verify that each API checks the user’s role, ownership, and permission before allowing the requested action. 

3. Object-Level Access Control 

Wallet IDs, transaction IDs, account IDs, withdrawal IDs, and other object references should be tested for unauthorized access. Changing an identifier in an API request should not expose another customer’s information or allow actions on another account. 

4. Transaction Parameter Validation 

Transaction APIs should validate asset type, amount, destination, account, transaction state, and other important parameters on the server. Client-side restrictions should not be treated as the security control. 

5. Sensitive Data Exposure 

API responses should be checked for private wallet information, customer details, authentication data, internal identifiers, transaction information, and secrets that the requesting user does not need. 

6. API Rate Limits 

Sensitive operations such as login, OTP validation, withdrawal requests, transaction creation, and address verification should have suitable rate controls. Testing should check whether repeated requests can bypass these limits through different endpoints or request patterns. 

7. Deprecated API Endpoints 

Older API versions should be identified and tested. An outdated endpoint with weaker authentication or authorization can provide access to functions that are protected in the current application. 

8. Administrative API Access 

Administrative APIs should be tested separately for role enforcement and function-level authorization. A customer account should not be able to invoke administrative API functions by changing request parameters or endpoint paths. 

Can Broken Authorization Expose Wallet or Transaction Data? 

Broken authorization can allow a valid customer account to access resources belonging to another customer or to perform functions reserved for administrators. OWASP specifically highlights object-level and function-level authorization as major API security areas. 

1. Changing Wallet Identifiers 

Test whether changing a wallet identifier in a request exposes another user’s wallet details or allows wallet-related actions. 

2. Changing Transaction Identifiers 

Transaction IDs should be checked against the authenticated user’s ownership and permissions. Changing the ID should not provide access to another customer’s transaction details. 

3. Accessing Another User’s Assets 

Testing should determine whether a customer can view balances, wallets, deposits, withdrawals, or other asset information belonging to another account. 

4. Viewing Restricted Transaction Details 

Transaction details should be limited according to the user’s role and ownership. Testing should check direct API requests, exported data, transaction history, and alternate endpoints. 

5. Modifying Another User’s Wallet Settings 

Changing a wallet ID or account reference should not allow modifications to another customer’s wallet settings, withdrawal addresses, limits, or security preferences. 

6. Accessing Administrative Resources 

Customer accounts should not be able to access administrative functions through hidden URLs, API endpoints, changed HTTP methods, manipulated role parameters, or direct requests. 

What Should Be Tested in Digital Asset Admin Workflows? 

Administrative workflows require detailed testing because they can affect many customer accounts and platform functions. The assessment should verify both admin authentication and authorization for every sensitive operation. 

1. Admin Login Controls 

Test administrator authentication, MFA enforcement, failed login handling, session management, password recovery, and access from unauthorized accounts. 

2. Administrative API Access 

Administrative API endpoints should verify the administrator’s role and permission for every sensitive operation. A valid token alone should not provide unrestricted administrative access. 

3. User Account Management 

Test functions for creating, disabling, modifying, locking, unlocking, or changing customer accounts. The assessment should check whether administrators can perform only the actions permitted by their assigned roles. 

4. Wallet Management Functions 

Wallet creation, wallet status changes, address management, transaction holds, and other wallet controls should be tested for authorization and approval requirements. 

5. Transaction Approval Functions 

Transaction approval workflows should verify who is permitted to approve a transaction and whether an administrator can approve a transaction that they should not be allowed to approve. 

6. Withdrawal Management 

Admin withdrawal functions should be tested for approval controls, transaction ownership, destination validation, role restrictions, and protection against unauthorized changes. 

7. Asset Configuration 

Functions that control supported assets, transaction settings, limits, fees, network settings, or wallet configuration should be tested for restricted access and change authorization. 

8. Administrative Reports and Exports 

Reports and exports can contain customer, transaction, wallet, and operational information. Testing should verify access permissions, export restrictions, filtering controls, and protection of downloaded data. 

How Should Privilege Escalation Be Tested in Digital Asset Platforms? 

Privilege escalation testing should determine whether a lower-privileged account can reach functions or information assigned to a higher-privileged role. OWASP authorization guidance supports testing both object-level and function-level access controls. 

1. Customer-to-Admin Access 

Start with a controlled customer account and test whether it can access admin URLs, APIs, functions, or resources. 

2. Access to Restricted Functions 

Identify functions available to administrators but not customers, then test whether direct requests can reach those functions without the required role. 

3. Administrative API Requests 

Administrative API requests should be tested using lower-privileged accounts. Changing HTTP methods, parameters, IDs, or endpoint paths should not bypass authorization. 

4. Role Parameter Manipulation 

Test whether changing values such as role, user type, account type, or permission fields in requests can increase access. Server-side authorization should determine the user’s role rather than trusting client-supplied values. 

5. Function-Level Authorization 

Each sensitive function should verify whether the current user has permission to perform that action. This includes transaction approval, wallet management, account modification, withdrawal control, and asset configuration. 

6. Object-Level Authorization 

Even when a user has permission to use a function, access should be limited to the objects they are allowed to access. Testing should therefore compare access to the user’s own wallet or transaction with another customer’s object. 

7. Direct Access to Admin Interfaces 

Hidden admin pages should not be treated as protected simply because they are absent from customer-facing menus. Testing should include direct navigation and direct HTTP requests to administrative interfaces and related APIs. 

What Business Logic Issues Should a CERT-In Audit Test? 

For a digital asset platform, a CERT-In security audit should go beyond checking common technical vulnerabilities. Wallets, deposits, withdrawals, trading functions, transaction APIs, and administrative workflows all depend on business rules. A flaw in one rule can allow an otherwise valid user account to perform an action that should not be allowed. 

1. Bypassing Transaction Steps 

A digital asset transaction may involve several stages, such as creating a withdrawal request, confirming the destination address, completing MFA, passing risk checks, and finally submitting the transaction. The audit should verify that these stages cannot be skipped by calling APIs directly.  

The auditor should check: 

• Whether mandatory verification steps can be skipped 

• Whether an approval endpoint can be called without creating the required request 

• Whether a transaction can move directly from creation to completion 

• Whether API calls enforce the same workflow as the web or mobile interface 

• Whether changing parameters can bypass a required security check 

2. Reusing Completed Transactions 

A completed transaction or approval should normally not be usable again. Testing should determine whether a previously completed transaction ID, approval token, confirmation request, or idempotency value can be submitted again. 

The auditor can verify whether: 

• A completed withdrawal can be submitted again 

• A used approval token remains valid 

• A completed deposit or transfer can trigger another credit 

• A single transaction reference can be processed more than once 

• Retry mechanisms create duplicate financial operations 

This is particularly important where multiple services process the same transaction. 

3. Manipulating Transaction Values 

The server should calculate or verify important transaction values rather than trusting values supplied by the client. 

Testing should cover: 

• Amount changes after approval 

• Currency changes during a transaction 

• Changes to fees or exchange rates 

• Decimal and rounding errors 

• Zero or negative values 

• Very large values 

• Changes to destination assets 

• Changes to recipient addresses after confirmation 

4. Bypassing Account Limits 

Platforms often apply limits to withdrawals, deposits, transfers, trading, or API activity. The audit should test whether these limits remain effective across: 

• Multiple API requests 

• Multiple sessions 

• Different application interfaces 

• Different wallet functions 

• Repeated transactions 

• Concurrent requests 

• Different currencies or assets 

• Changes to account verification status 

5. Repeating Single-Use Functions 

Some functions are designed to work only once. Examples include: 

• Withdrawal approvals 

• Email verification links 

• MFA recovery codes 

• Transaction confirmation tokens 

• One-time bonuses 

• Address-verification actions 

• Account recovery actions 

The auditor should test whether these functions can be reused, replayed, or triggered concurrently. A useful test is to check both sequential reuse and parallel requests, because a function may reject a second request under normal conditions but still process two requests sent at almost the same time. 

6. Changing Transaction States 

Transactions normally move through defined states such as: 

Created → Pending → Approved → Processing → Completed 

An audit should determine whether a customer or lower-privileged user can force an invalid state change. 

Examples include: 

• Changing pending to completed 

• Cancelling a transaction after processing has started 

• Approving a transaction after it has been cancelled 

• Modifying transaction details after approval 

• Reopening a completed transaction 

• Changing the owner or recipient during processing 

Each state transition should be validated by the server. 

7. Processing Transactions Out of Order 

A workflow may require one operation to happen before another. The auditor should attempt to submit API requests in an unexpected sequence. 

For example: 

• Approval before transaction creation 

• Completion before approval 

• Withdrawal before account verification 

• Refund before payment confirmation 

• Final settlement before external confirmation 

How Should Authentication and MFA Be Tested? 

Authentication testing for a digital asset platform should cover both customer and privileged accounts. Administrative accounts deserve separate testing because compromise of one such account may affect many customer accounts. 

1. Customer Login 

Test whether customer authentication properly handles: 

• Invalid credentials 

• Account lockout or rate controls 

• Password reset 

• Email or mobile verification 

• Login from new devices 

• Session creation 

• Account status changes 

The audit should also check whether alternate login APIs enforce the same controls as the primary login interface. 

2. Admin Login 

Administrative authentication should be tested separately from customer authentication. 

The auditor should verify: 

• Strong authentication requirements 

• MFA enforcement 

• Role-specific access 

• Separate administrative sessions 

• Restrictions on administrative interfaces 

• Login monitoring 

• Session timeout 

• Protection against authentication bypass 

An administrator should not gain access to functions simply by changing a role value in a request or using a customer session. 

3. MFA Enforcement 

MFA should protect the actions that require additional approval, not just the initial login. 

Testing should include: 

• MFA during login 

• MFA during withdrawals 

• MFA for API-key changes 

• MFA for password changes 

• MFA for security-setting changes 

• MFA for adding withdrawal addresses 

• MFA for privileged administrative actions 

The auditor should check whether sensitive APIs can be called without completing the expected MFA step. 

4. MFA Recovery 

Recovery mechanisms can become an alternative path around MFA. 

Test: 

• Lost-device recovery 

• Backup codes 

• Email-based recovery 

• Phone-number changes 

• Help-desk recovery 

• Recovery after password reset 

• Recovery from a new device 

The key question is whether the recovery process provides security comparable to the MFA control it replaces. 

5. Session Management 

The audit should check: 

• Session expiry 

• Logout invalidation 

• Concurrent sessions 

• Session renewal 

• Session changes after password updates 

• Session changes after MFA changes 

• Administrative session handling 

• Access after account suspension 

Sensitive actions should not remain available through an old session after the relevant security setting has changed. 

6. Authentication Token Handling 

Authentication and authorization tokens should be tested for: 

• Predictability 

• Expiration 

• Revocation 

• Scope 

• Reuse 

• Exposure through URLs or logs 

• Exposure in API responses 

• Cross-account use 

A token belonging to one account must not provide access to another account or another wallet. 

7. Failed Login Controls 

Test whether repeated authentication failures trigger the intended controls. 

The audit should examine: 

• Login rate limits 

• Password-reset rate limits 

• MFA attempt limits 

• Account lock or temporary restrictions 

• Alerts for unusual authentication activity 

• Controls across multiple sessions and IP addresses 

What Sensitive Data Should Be Checked During the Audit? 

A digital asset audit should examine where sensitive information is stored, processed, returned, logged, and transmitted. 

1. Wallet Addresses 

Check whether wallet addresses are unnecessarily exposed through: 

• Public APIs 

• Customer-to-customer responses 

• Logs 

• Error messages 

• Browser storage 

• Debug interfaces 

• Administrative reports 

Wallet addresses may not always be secret, but unnecessary exposure can disclose sensitive transaction relationships and customer information. 

2. Transaction Information 

Review exposure of: 

• Transaction IDs 

• Amounts 

• Asset types 

• Deposit and withdrawal history 

• Destination information 

• Internal transaction references 

• Transaction metadata 

Access should be limited according to the user’s role and ownership. 

3. Customer Information 

Check for exposure of: 

• Names 

• Email addresses 

• Phone numbers 

• KYC information 

• Identity documents 

• Account information 

• Bank-related information 

• Customer verification status 

The audit should test whether one customer can obtain another customer’s information through APIs or predictable identifiers. 

4. Authentication Tokens 

Look for tokens in: 

• API responses 

• Browser storage 

• URLs 

• Application logs 

• Error messages 

• Monitoring systems 

• Support tools 

Sensitive tokens should not appear where users or unauthorized personnel can access them. 

5. API Keys and Secrets 

The audit should check application code, configuration, CI/CD systems, cloud resources, and exposed endpoints for: 

• API keys 

• Private credentials 

• Database passwords 

• Cloud credentials 

• Service-account tokens 

• Encryption keys 

• Third-party credentials 

Secrets should also have appropriate scope and permissions. 

6. Administrative Data 

Administrative interfaces can expose information that ordinary customers should never receive. 

Testing should cover: 

• Internal user IDs 

• Account status 

• Risk information 

• Internal notes 

• Support records 

• Security events 

• Transaction review information 

• Privileged API responses 

7. Sensitive Data in API Responses 

An API may enforce access to the requested object while still returning unnecessary fields. For example, an otherwise valid customer API response may contain internal IDs, security flags, administrative information, or data belonging to another service. The audit should review complete JSON/XML responses rather than only the fields visible in the user interface. 

How Should Payment and Asset Transfer Integrations Be Tested? 

Digital asset platforms often depend on multiple external services. CERT-In’s 2021 advisory notes that audits should consider the wider cyber infrastructure rather than limiting the assessment to websites or web applications. 

1. Payment Gateway APIs 

Test whether payment status is trusted without sufficient verification. 

The auditor should check: 

• Payment confirmation 

• Amount matching 

• Currency matching 

• Transaction identifiers 

• Duplicate callbacks 

• Failed payment handling 

• Refund handling 

A failed payment should not result in a successful asset credit. 

2. Banking Integrations 

Review: 

• Account ownership checks 

• Payment status 

• Amount reconciliation 

• Duplicate transaction handling 

• Failed transfers 

• Reversed transactions 

• Callback authentication 

The platform should not treat an unverified banking response as final proof of payment. 

3. Blockchain or Network APIs 

Check how the platform handles external blockchain information. 

Testing should include: 

• Transaction confirmation 

• Confirmation depth 

• Failed transactions 

• Replaced or conflicting transactions 

• Incorrect network selection 

• Asset/contract identification 

• Deposit address mapping 

• Network-specific transaction status 

4. Custody Service Integrations 

If a separate custody provider handles assets, test whether the platform correctly controls: 

• Withdrawal requests 

• Approval states 

• Destination addresses 

• Asset types 

• Amounts 

• Custody API permissions 

• Callback processing 

A weakness in the connection between the platform and custody provider can affect the entire transaction process. 

5. Transaction Callbacks 

Callbacks and webhooks should be treated as security-sensitive inputs. 

Test whether the system verifies: 

• Callback authenticity 

• Request signatures 

• Transaction IDs 

• Amounts 

• Asset types 

• Customer/account mapping 

• Transaction state 

Repeated callbacks should not create repeated credits. 

6. External Transaction Status 

The platform should not blindly trust a third-party status such as success, confirmed, or completed. The audit should compare external status with the platform’s own transaction state and business rules. 

7. Third-Party API Authentication 

Review: 

• API key scope 

• Secret storage 

• Token expiration 

• Certificate validation where applicable 

• Request signing 

• IP restrictions 

• Service-account permissions 

• Credential rotation 

What Security Configurations Should Be Reviewed? 

CERT-In’s audit guidance calls for appropriate audit scope across the organization’s cyber infrastructure, including systems, applications, networks and cloud environments where applicable.  

1. Internet-Facing Admin Interfaces 

Check whether administrative services are unnecessarily exposed to the Internet. 

Review: 

• Administrative URLs 

• Remote access services 

• Management APIs 

• Access restrictions 

• MFA 

• Network controls 

• Administrative authentication 

2. API Security Settings 

Review: 

• Authentication requirements 

• Authorization rules 

• Rate limits 

• CORS configuration 

• TLS settings 

• API gateway rules 

• Request-size limits 

• Error handling 

• Deprecated API versions 

3. Cloud Access Controls 

Review: 

• IAM roles 

• Service accounts 

• Privilege levels 

• Cross-account access 

• Storage access 

• Security groups 

• Public exposure 

• Key management 

4. Database Permissions 

Check whether applications, administrators, reporting tools, and service accounts have more database access than required. 

Particular attention should be given to databases containing: 

• Wallet records 

• Transaction records 

• Customer data 

• Authentication information 

• Audit records 

5. Storage Permissions 

Review cloud buckets, file stores, backups, and shared storage for accidental public or broad access. 

6. Network Security Rules 

Check: 

• Firewall rules 

• Security groups 

• Network segmentation 

• Administrative access 

• Database exposure 

• Service-to-service communication 

Critical systems should not be directly accessible from networks where access is unnecessary. 

7. Logging and Monitoring 

Logs should support investigation of: 

• Login attempts 

• MFA activity 

• Wallet changes 

• Withdrawals 

• Administrative actions 

• API-key changes 

• Permission changes 

• Transaction-state changes 

8. Test and Development Endpoints 

Look for: 

• Debug APIs 

• Swagger/OpenAPI interfaces 

• Test endpoints 

• Staging systems 

• Development consoles 

• Sample accounts 

• Disabled authentication 

• Test credentials 

A forgotten development endpoint can provide access to production functions. 

How Should a CERT-In Auditor Trace a Complete Digital Asset Attack Path? 

The goal should not be to test isolated vulnerabilities only. The auditor should understand how several weaknesses could combine to affect a wallet, transaction, account, or administrative function. 

1. Start With a Controlled Customer Account 

Use an authorized test account with known permissions and test assets. 

This creates a safe starting point for testing customer-side functions. 

2. Map Available Wallet Functions 

Document functions such as: 

• Deposit 

• Withdrawal 

• Transfer 

• Address management 

• Asset conversion 

• Transaction history 

• Security settings 

3. Identify Transaction APIs 

Map the API requests used for each function and identify which requests create, approve, modify, or complete transactions. 

4. Test Authorization Controls 

Test whether the account can access: 

• Its own resources 

• Another test account’s resources 

• Restricted functions 

• Administrative endpoints 

• Objects belonging to a different user 

Authorization should be checked at the object and action level, not only at login. 

5. Test Transaction Workflows 

Check: 

• Step skipping 

• Step repetition 

• State changes 

• Value changes 

• Transaction replay 

• Concurrent requests 

• Transaction cancellation 

• Transaction ordering 

6. Test Administrative Functions 

Using an authorized test administrator, examine whether roles correctly restrict: 

• Customer account changes 

• Wallet controls 

• Withdrawal approval 

• Transaction review 

• API-key management 

• Security-setting changes 

7. Trace Access Across Connected Services 

Follow the transaction from the application to relevant: 

API gateway → transaction service → database → custody service → payment/banking service → blockchain/network service 

This can reveal authorization gaps between individual systems. 

8. Verify the Final Security Impact 

The auditor should stop at the point needed to prove the issue. 

For example, if a workflow flaw demonstrates that a transaction can be processed without a required approval, there is usually no need to perform an actual unauthorized asset transfer. 

What Evidence Should Be Documented During the Audit? 

Good evidence allows the organization to reproduce the finding and understand exactly which control failed. 

1. Affected Application or API 

Record: 

• Application name 

• API/service 

• Endpoint 

• Environment 

• Version where relevant 

2. Affected Wallet or Transaction Function 

Clearly identify whether the issue affects: 

• Deposit 

• Withdrawal 

• Transfer 

• Trading 

• Wallet management 

• Account recovery 

• Administration 

3. Test Account and User Role 

Record the role used for testing, such as: 

• Customer 

• Verified customer 

• Support user 

• Finance user 

• Administrator 

Avoid placing unnecessary personal information in the report. 

4. Request and Response Evidence 

Capture appropriate evidence showing: 

• Request 

• Relevant parameters 

• Response 

• HTTP status 

• Transaction/reference ID 

• Before-and-after state 

Sensitive secrets should be masked in the report. 

5. Security Control That Failed 

State the exact failed control. 

For example: The transaction API accepted a completion request without confirming that the required approval state had been reached. 

This is more useful than simply describing the issue as an “authorization vulnerability.” 

6. Business Impact 

Explain what the weakness could allow an attacker or unauthorized user to do. 

For a digital asset platform, possible impacts include: 

• Unauthorized transaction processing 

• Duplicate credits 

• Unauthorized withdrawals 

• Customer-data exposure 

• Administrative account compromise 

• Transaction manipulation 

• Loss of transaction integrity 

7. Recommended Remediation 

The recommendation should identify the required control. 

Examples include: 

• Enforce server-side workflow states 

• Recalculate transaction values on the server 

• Apply object-level authorization 

• Use atomic transaction processing 

• Enforce single-use tokens 

• Verify third-party callbacks 

• Apply MFA to sensitive operations 

• Reduce service-account permissions 

• Improve transaction logging 

Why Should Digital Asset Platforms Include Wallet, Transaction and Admin Testing in VAPT? 

A standard vulnerability scan may identify technical weaknesses, but it may not understand whether a transaction is being processed in the correct business state.  

1. Wallet Functions Handle Valuable Assets 

Wallet operations directly affect customer balances, deposits, withdrawals, and transfers. A small workflow mistake can therefore have a significant financial effect. 

2. Transaction APIs Control Financial Operations 

APIs may create, approve, modify, and complete transactions. Each stage needs its own authorization and state checks. 

3. Authorization Failures Can Expose User Assets 

A user who is properly authenticated may still be unauthorized to perform a particular action or access a particular wallet.  

4. Business Logic Issues Can Affect Transaction Integrity 

A platform can have secure passwords, encryption, and network controls while still allowing a transaction to be processed incorrectly because of a workflow flaw. 

5. Admin Functions Can Control Multiple User Accounts 

Administrative access can affect customer balances, transaction approvals, security settings, and account permissions. Admin testing should therefore receive separate attention. 

6. APIs Can Connect Multiple Critical Services 

A transaction can pass through several systems. A security check that exists in one service may be missing in another. 

The audit should therefore examine the complete transaction chain rather than testing each API in isolation. 

7. Manual Testing Can Identify Workflow Weaknesses 

Manual testing is particularly useful for questions such as: 

• Can this step be skipped? 

• Can this transaction be approved twice? 

• Can the amount change after approval? 

• Can a cancelled transaction become active again? 

• Can two requests spend the same balance? 

• Can a customer reach an administrative function? 

• Does the external payment status match the platform’s transaction state? 

These are business questions as much as technical questions. 

Final Takeaway 

For a digital asset platform, a CERT-In audit should test how the platform behaves when a user does something outside the intended workflow, not only whether known software vulnerabilities exist. 

The strongest assessment combines VAPT, authorization testing, business-logic testing, API testing, configuration review, integration testing, and evidence-based attack-path analysis. This approach aligns with CERT-In’s broader audit guidance and with OWASP’s recommendations for testing workflow and business-rule weaknesses.  

For compliance purposes, the exact audit scope should also be mapped to the platform’s applicable CERT-In requirements and any sector-specific regulations that apply to its payment, custody, banking, or virtual-asset activities. 

Looking to assess the security of your digital asset platform? Talk to Peneto Labs today and take the next step toward a more secure and compliant digital environment.