Web3 security conversations tend to fixate on smart contract audits. And while those are critical, they represent just one layer of a much larger attack surface. If your contracts are bulletproof but your ops are held together with duct tape, you're still one phishing email away from a headline.
This article presents a practical threat model for RandomExampleFinance, a hypothetical small web3 startup, to illustrate why "smart contracts - clean" doesn't mean "secure."
Core Assets to Protect
Before diving into attack vectors, let's identify what we're actually defending:
Private keys controlling company funds- The funds themselves
- User-facing applications
- Domain trust and social media accounts
Six Critical Attack Vectors
1. Smart Contract Exploits
Risk: Logic or coding flaws enabling fund theft
Mitigations:
- Professional smart contract audits
- Ongoing bug bounty programs
- Verify any post-audit code changes with auditors
Key insight: Point-in-time audits don't guarantee ongoing security as vulnerabilities evolve.
2. Web2 Exploits (No User Interaction)
Risk: Remote exploitation of server infrastructure without requiring user action
Critical considerations:
- Orphaned infrastructure, dangling CNAMEs, subdomain takeover risks
- AI agent exposure to prompt injection attacks
- Exposed ports and unpatched services
- Hardcoded secrets in repositories and JavaScript
Mitigations:
- Complete asset inventory of all subdomains, servers, and cloud resources
- Cloudflare protection for customer-facing infrastructure
- Internal-only access for non-public systems
- Secret rotation and automated secret detection using tools like trufflehog
- Blackbox OSINT assessment before whitebox penetration testing
3. Web2 Exploits (With User Interaction)
Risk: Compromised websites distributing malicious scripts that convince users to approve harmful transactions
Examples:
- Third-party data providers serving malicious code
- Hijacked external scripts through compromised dependencies
Frontend hardening controls:
- Subresource Integrity (SRI)
- Content Security Policy (CSP)
- Secure cookie flags
- CORS headers configuration
Mitigations:
- Implement SRI, CSP, and proper cookie flags
- Avoid auto-updating dependencies
- Treat third-party scripts as inherently untrusted
Critical note: "Your frontend is only as secure as the least secure third-party script it loads."
4. Targeted Attacks on Key Holders
Risk: Compromised employees leading to stolen private keys and credentials
Threat scenarios:
- Long-term phishing relationships building trust before delivering malware
- Remote access trojans (RATs) with stealer modules
- Account takeovers (AWS, Gmail)
- SIM swapping attacks
Mitigations:
- Hardware-based or KMS key management
- Dedicated signing machines for key operations only
- Multi-factor authentication (application-based preferred)
- Never store production keys on personal laptops
- Compartmentalize key access by role
Pro tip: "If your lead dev has the production key on his laptop because he was 'just testing deployment' — that's your biggest vulnerability."
5. Supply Chain and Dependency Attacks
Risk: Third-party compromises or dependency hijacking leading to code injection
Concerns:
- Automatic dependency updates creating vulnerability windows
- Compromised maintainers or packages
- Scope limitations in audits excluding third-party integrations
Mitigations:
- Pin dependency versions using lockfiles
- Review diffs before merging updates
- Maintain inventory of external integrations and their access levels
- Understand blast radius of each third-party integration
Key insight: "'We'll just use latest' is a bet that every maintainer will never get compromised."
6. Governance, Multisig, and Insider Threats
Risk: Malicious or compromised employees abusing governance access
Vulnerabilities:
- Absent review processes for multisig operations
- Inadequate offboarding procedures
- Former employees retaining access
Mitigations:
- Map critical procedures requiring multisig approval
- Require transaction verification before signing
- Formal offboarding revoking all access
- MFA on all accounts
- Maintain access audit trails
Investment Priorities for Small Companies
Layer 1: Smart Contract Security
Five-stage approach:
Security-Oriented Design — Adversarial thinking, threat modeling, comprehensive unit tests with coverage measurement
Low-Hanging Fruit Review — AI-assisted analysis and open-source audit tools from reputable sources
Private Audit — Smaller audit firms or independent researchers at lower rates
Established Audit Firm — Premium auditors focusing on edge cases and complex vectors
Optional Bug Bounty — Ongoing community security engagement or security.txt contact for responsible disclosure
Goal: Expensive final audits should find minimal issues, indicating earlier layers caught obvious problems.
Layer 2: Infrastructure and Asset Management
Internet-facing assets:
- Enable Cloudflare WAF and rate limiting
- Disable direct IP access
- Conduct blackbox OSINT discovery
- Perform whitebox security reviews including code audits
Non-public infrastructure:
- Hide via IP whitelisting or internal networks
- Deny all by default, grant only necessary access
- Require MFA on all user accounts
Layer 3: Security Culture
Rather than mandatory phishing simulations or awareness training, foster organic security discussions:
- Monthly security discussions analyzing recent incidents
- Brainstorm potential improvements
- Consider adversarial perspectives on features
- Build security awareness gradually
Philosophy: Become harder to breach than competing targets at similar risk/reward ratios.
Layer 4: Threat Modeling
Encourage team-based threat modeling using frameworks like STRIDE:
Spoofing: Fake logins, stolen credentials, forged tokens
Tampering: Altered transactions, modified configs, injected scripts
Repudiation: Missing audit logs, unsigned transactions
Information Disclosure: Leaked keys, verbose errors, exposed .env files
Denial of Service: DDoS, resource exhaustion, gas griefing
Elevation of Privilege: Missing access controls, privilege escalation, admin bypass
Key Conclusions
No audit covers your ops. No tool covers your people. Post-mortems typically reveal that processes — not code — were the failure point.
Perfect security remains impossible, but implementing security-conscious culture and layered security services significantly reduces breach likelihood under normal circumstances.
Final observation: "The weakest link in every incident post-mortem isn't the code — it's a process someone skipped because it was inconvenient that day."