Decentralized Application Code Review and Security Analysis Methodology
Release: Version 2.0
Document
| Field | Description |
|---|---|
| Name | Blockchain protocol and security analysis methodology |
| Creators | Hacken OU |
| Subject | Audit; security analysis; dApp; pentest; attack vectors; |
| Description | The methodology outlined in this document offers specific guidance on how to plan and execute an audit of decentralized applications (s) developed by Hacken OU. This document aims to equip all relevant stakeholders with a comprehensive understanding of the auditing process, as well as the steps needed to adequately prepare for it. |
| Author | Stephen Ajayi | dApp Audit Technical Lead at Hacken |
| Date | October 15th, 2025 |
| Rights | Hacken OU |
Introduction
This document describes the secure code review and security analysis process for Web2 components of decentralized applications including wallets, bridges, oracles, APIs, middleware, backends, frontends, Bitcoin ordinals integrations, and other codebases that interface with blockchain or Web3 services.
The framework is tailored to traditional Web2 programming languages (JavaScript, TypeScript, Java, C/C++, Python, Go, Rust, Node.js, etc.) and addresses security risks that typically arise in these environments. The specific risks depend on the application under review, but commonly include:
- Insecure handling of cryptographic materials.
- Unsafe integration with blockchain SDKs (e.g., web3.js, ethers.js, web3.py, bitcoinlib, ordinals libraries).
- Insecure API design and exposure (wallets, bridges, RPC endpoints).
- Misconfigured infrastructure (containers, CI/CD, cloud environments).
Alignment with International Standards
The methodology draws from industry-recognized standards and guidelines, including the NIST Secure Software Development Framework (SSDF), OWASP ASVS, OWASP WSTG, OWASP Code Review Guide, and CERT Secure Coding Standards. These provide a structured foundation for ensuring consistency, accountability, and measurable compliance in security testing.
The review process also follows the CIA triad (Confidentiality, Integrity, Availability) while extending it with blockchain-specific concerns such as:
- Transaction finality and replay prevention.
- Private key custody and protection.
- Cross-chain data validation and consensus risks.
- Resilience against node provider manipulation.
Code Review and Security Analysis
Requirements
This methodology is specifically designed for applications that interface with blockchain networks. While it can be applied to conventional Web2 applications, its focus and effectiveness are optimized for blockchain-related systems. The following criteria define when this methodology is most appropriate.
Eligibility Criteria ("any of"):
| # | Criteria |
|---|---|
| 1 | Interact with blockchain networks via APIs, SDKs, or libraries (e.g., web3.js, ethers.js, bitcoin ordinals indexers). |
| 2 | The application has custody over or interacts with sensitive information such as private keys, seed phrases, etc. |
| 3 | The application signs and/or broadcasts transactions without relying on third-party injected/connected providers. |
| 4 | Consume and respond to blockchain events (e.g., transaction confirmations, mempool monitoring, smart contract event subscriptions). |
| 5 | Provide custodial or semi-custodial wallet services (e.g., hot/cold storage, browser extensions, mobile wallets). |
| 6 | Bridge digital assets or coordinate cross-chain operations through Web2 middleware. |
| 7 | Execute high-value business logic tied to on-chain finalization (e.g., trading platforms, NFT marketplaces, cross-chain DeFi applications). |
Methodology Steps
This methodology requires the following resources to be provided:
- The source code with a clearly defined scope.
- The documentation with functional requirements and technical details about the application.
1. Scoping & Planning
- Application understanding – Identify all Web2 components, frameworks, programming languages, and blockchain integrations involved in the system.
- Complexity assessment – Evaluate the size of the codebase, framework dependencies, cryptographic libraries, and blockchain integration points.
- Client alignment – Define engagement scope, timelines, and effort estimates based on system complexity and the exposed risk surface.
- Architecture mapping – Document the system architecture, including data flows between frontend, backend, blockchain nodes, and external providers.
2. Requirements & Threat Modeling
- Business context analysis – Identify critical assets such as user funds, transactions, and identities.
- Security requirement derivation – Map requirements to OWASP ASVS (chosen level) and NIST 800-53 / SP 800-218 (SSDF) controls.
Common Areas of Emphasis
While exact risks vary across applications, the following areas are frequently critical:
- Authentication and wallet-based login – Implement secure challenge–response schemes (e.g., EIP-4361 Sign-In with Ethereum). Nonces must be unique, time-bound, and properly validated.
- Session management – Securely handle token issuance, renewal, invalidation, and storage in line with OWASP and NIST guidance.
- Authorization – Enforce least privilege, validate role mappings against business rules, and avoid implicit trust in blockchain events.
- Blockchain event and input sanitization – Treat blockchain data as untrusted input. Validate origin, format, and size.
- Cryptography – Use only approved algorithms (NIST-approved or blockchain standards). Verify libraries for compliance with FIPS 140-3 where applicable.
- Transaction finality and replay protection – Apply confirmation thresholds, reorganization handling, nonce tracking, and duplicate prevention.
- Data protection – Require TLS 1.3 for data in transit and AES-GCM or ChaCha20-Poly1305 for data at rest. Protect in-memory secrets with language-specific safeguards.
- Secure logging and error handling – Prevent sensitive data leakage. Avoid exposing stack traces, RPC URLs, or private keys in error messages.
- API and bridge security – Validate payloads, enforce rate limits, and apply strong authentication for cross-chain and external APIs.
Threat Modeling Enhancements
To capture domain-specific risks, the STRIDE framework is combined with attack tree analysis. Typical considerations include:
- Wallet-based authentication (spoofing, replay attacks)
- Bridge operations (man-in-the-middle, double execution)
- Backend node communication (tampering or manipulation by compromised providers)
- Ordinals metadata handling (cross-site scripting or external entity injection from on-chain or off-chain data)
3. Evidence & Environment Preparation
Access & documentation
- Build instructions, environment variables, and CI/CD pipeline details
- Secure coding guidelines already adopted by the client (if any)
Test environments
- Local VM or containerized staging environment with blockchain connectivity
- Testnet or forked blockchain nodes for runtime testing
Dynamic analysis readiness
- Ensure staging supports functional testing and DAST where applicable
- Provide access to mock wallets, bridge APIs, and test credentials
4. Analysis and Testing
The analysis and testing phase is iterative. It combines automated scanning, static analysis, manual review, and runtime testing. Each stage builds on the last to progressively uncover vulnerabilities and evaluate the security posture of the application.
Automated Baseline Checks
- Software composition analysis – Detect vulnerable or outdated third-party libraries and dependencies.
- Secrets detection – Identify accidental exposure of sensitive information such as API keys, wallet mnemonics, or blockchain endpoint URLs.
- Infrastructure and container security review – Assess cloud configurations, container definitions, and orchestration manifests for misconfigurations (e.g., insecure Dockerfiles or Kubernetes files).
Static Analysis
Static analysis examines source code without execution to uncover hidden weaknesses and ensure resilience in complex systems.
- Quick rule scan – Lightweight checks for common issues such as code injection and unsafe API usage.
- Targeted rule scan – Custom rules for blockchain-specific risks, including cryptographic misuse, insecure network communication, and session mismanagement.
- Standards mapping – Findings are aligned with recognized industry references, including:
- OWASP Application Security Verification Standard (ASVS)
- NIST Secure Software Development Framework (SSDF)
- CERT Secure Coding Standards (language-specific)
Manual Review and Security Testing
Manual review and runtime testing provide the most context-aware layer of analysis. These methods adapt to the unique design, architecture, and business logic of each application, uncovering vulnerabilities specific to blockchain integration and sensitive data handling.
Code Review (Risk-Focused)
A detailed, line-by-line examination is performed on high-risk and business-critical components. Areas commonly reviewed include:
- Authentication flows (wallet-based login mechanisms)
- Session and token handling (expiration and renewal logic)
- Authorization enforcement (role- or attribute-based access control)
- Input validation and blockchain event sanitization
- Cryptographic operations (digital signatures, hashing, encryption)
- Logging and error handling (preventing sensitive data leakage)
- Transaction execution tracing (from entry to signing and confirmation)
- Application-specific logic that affects on-chain outcomes or high-value operations
Security Testing (Runtime Validation)
Testing in controlled environments validates whether code-level findings are exploitable and identifies risks not visible in static review. Activities include:
- Step-by-step functional audit (guided testing using OWASP WSTG and tailored threat models)
- Business logic validation (race conditions, double-spending, bridge misrouting, replay attacks)
- Dynamic security testing (runtime protections, injection handling, error exposure, resilience testing)
Reference Materials
The review process is guided by authoritative resources, including:
- OWASP Code Review Guide
- OWASP Web Security Testing Guide
- CERT Secure Coding Standards (language-specific)
- Official blockchain SDK documentation (e.g., web3.js, ethers.js, web3.py, bitcoinlib)
Assessment Criteria and Reporting
The review process is designed to surface both widely known software weaknesses and blockchain-specific risks. Because each application type (for example, wallets, bridges, oracles, middleware, exchanges) exposes a different attack surface, the framework uses a hybrid approach:
- Baseline security controls – A standardized set of checks applied across all reviews (for example, key management, authentication, dependency hygiene, data validation). These provide comparability between projects.
- Context-specific controls – Additional checks derived from the application’s architecture, business logic, and integration patterns. These ensure relevance to the unique risks of the system under review.
Severity Levels
Findings are categorized based on their potential impact and assigned a severity level using the Common Vulnerability Scoring System (CVSS) version 4.0:
| Severity | Description |
|---|---|
| Critical | These issues present a major security vulnerability that poses a severe risk to the system. They require immediate attention and must be resolved to prevent a potential security breach or other significant harm. |
| High | These issues present a significant risk to the system but may not require immediate attention. They should be addressed in a timely manner to reduce the risk of a potential security breach. |
| Medium | These issues present a moderate risk to the system and are unlikely to have a major impact on its function. They should be addressed in a reasonable timeframe but may not require immediate attention. |
| Low | These issues present minimal risk to the system and typically relate to code quality or general recommendations. They do not require immediate attention and should be viewed as minor improvements. |
Issue Lifecycle
To promote transparency, each issue progresses through one of the following states:
| Status | Description |
|---|---|
| Pending Fix | The issue was reported but not yet addressed. |
| Accepted | The client chooses not to remediate and accepts the residual risk. |
| Resolved | The issue was successfully remediated and no longer poses risk. |
5. Standards Cross-Reference
All identified issues during the secure code review are classified and mapped against recognized industry standards to ensure clarity and consistency.
Each issue is linked to:
- CWE (Common Weakness Enumeration) – standardized weakness categories.
- OWASP Application Security Verification Standard (ASVS) – relevant security controls.
- CERT Secure Coding Standards – language-specific coding practices.
- CVSS v4.0 – severity scoring based on impact and exploitability.
Assessment Report
The reporting phase delivers a complete record of all findings from the code review and security analysis. Reports are structured to ensure transparency, reproducibility, and actionable remediation guidance.
Key Principles
- Continuous access – Clients have visibility into findings throughout the testing process, not only upon final delivery.
- Final report contents – The final deliverable consolidates all verified issues and their context.
Final Report Structure
Each identified issue should include:
- Title and description – Clear summary of the vulnerability.
- Impact assessment – Business and technical consequences if exploited.
- Standards references – Mappings to CWE, CERT, and NIST guidance.
- Affected code snippets – Exact lines or functions where the issue occurs.
- Reproduction steps or proof of concept – When applicable, instructions or demonstrations to validate the finding.
- Severity rating – Scored using CVSS version 4.0.
- Remediation guidance – Prioritized recommendations with code samples where possible.
Limitations
While this methodology is designed to identify specific risks and vulnerabilities in the application through a thorough code review and security analysis, it is important to note that it does not make any statements or warranties regarding the overall security of the application.
To ensure the security of a decentralized application, it is strongly recommended not to rely solely on this methodology. Multiple independent audits and the implementation of a public bug bounty program are advised to further identify and address potential security issues.
Stay in Touch
We’re excited to share our expertise and help you build a safer web3 future. If you have any questions, feel free to contact us.