When Six STRIDE Categories Meet Five Defensive Layers
STRIDE threat modeling: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege. Microsoft's six-category taxonomy for systematic threat analysis. Industry-standard. Battle-tested. Comprehensive—allegedly.
Here's where numerology meets reality: Mapping STRIDE to the CIA Compliance Manager architecture revealed six categories compressing into five defensive requirements. Denial of Service? Defeated by architectural simplicity (static hosting eliminates 90% of DoS attack surface). The remaining five threats align perfectly with five defensive layers. Coincidence? Or the universe revealing optimal security structure through constraint?
Challenge conventional security thinking: More threat categories don't guarantee comprehensive defense. Overlapping categories create false coverage confidence. Our five-layer defense addresses all six STRIDE threats because layers are orthogonal—each protecting fundamentally different attack surfaces. Pattern recognition enabling defensive efficiency over exhaustive categorization.
Illumination: Six STRIDE categories mapping to five defenses reveals which threats share root causes. Spoofing + Elevation of Privilege both defeated by authentication. Tampering + Repudiation both defeated by integrity controls. Pattern recognition enabling defensive efficiency.
The Client-Side Security Advantage
Conventional compliance tools: server-side SaaS. Users upload sensitive data. Vendor stores it. Vendor secures it. Vendor sells "enterprise security" as competitive advantage.
We chose differently. Client-side application. IndexedDB storage. No backend. Data never leaves user's browser. Attack surface: minimal. Why?
Five advantages of client-side architecture for compliance:
- Zero Server Vulnerabilities: No SQL injection (no SQL server). No RCE (no command execution). No SSRF (no server-side requests). No XXE (no XML parsing). Entire OWASP Top 10 mostly irrelevant. Attack surface collapsed.
- Data Sovereignty By Default: User data in user's browser on user's device under user's control. No "our privacy policy says..." marketing. Mathematical privacy through architecture. GDPR compliance automatic.
- Offline Operation: Internet down? Compliance assessment continues. Network compromised? Sensitive data already local. Air-gapped environments? Install once, run forever. Resilience through independence.
- Transparent Security: Client-side JavaScript means users can audit security. View source. Read the code. Verify cryptographic implementations. Trust through verification, not vendor promises.
- Cost Reduction: No server costs = $0/month hosting. GitHub Pages free. CloudFlare free tier. Zero hosting fees enabling free open-source tool. Economic sustainability through architectural simplicity.
Tradeoffs acknowledged: No server = no real-time collaboration (roadmap: peer-to-peer via WebRTC). No centralized backup (roadmap: encrypted cloud export). Client-side limits (roadmap: Web Workers for heavy computation). Honest tradeoff documentation > marketing spin.
Security architecture that eliminates entire attack classes beats security architecture defending against every attack in every class. Choose simplicity enabling security over complexity requiring security.
Client-Side Security Architecture: Defense Through Simplicity
Each security layer addresses specific threat categories. Client-side architecture fundamentally eliminates server-side attack vectors while requiring careful defense of browser-based threats.
1. 🌐 Content Security Policy: Injection Defense
Threats mitigated: Cross-site scripting (XSS), data exfiltration via injected scripts, unauthorized resource loading.
CSP directives: Restrictive policy limiting script sources, style sources, and connection endpoints. Configuration deployed via GitHub Pages headers.
React framework protection: Automatic XSS prevention through JSX escaping, DOM manipulation sanitization, and controlled prop rendering.
CSP that blocks legitimate functionality fails usability. CSP that allows everything fails security. Balance through minimum necessary directives based on actual application requirements.
2. 🔐 Subresource Integrity: Dependency Trust
Threat mitigated: Compromised CDN serving malicious library versions, supply chain attacks on external dependencies.
SRI implementation: Cryptographic hash validation for external resources. Dependency integrity verification at build time.
Supply chain verification: Dependabot automation for security updates, FOSSA license compliance scanning. Evidence: FOSSA dashboard.
3. 🛡️ Type Safety: Runtime Error Prevention
Threats mitigated: Type confusion vulnerabilities, runtime errors causing denial of service, malformed data processing.
TypeScript strict mode: Comprehensive type checking with noImplicitAny, strictNullChecks, strictFunctionTypes compilation flags. Type errors block builds.
Build-time validation: ESLint static analysis, TypeScript compiler checks, Vite build optimization with tree-shaking removing unused code.
4. 🔒 Data Protection: Browser Storage Security
Threat mitigated: Local storage compromise, unauthorized data access from malicious extensions or co-located attacks.
Current implementation: IndexedDB within browser sandbox. Relies on OS-level disk encryption and browser profile security for data-at-rest protection.
Future enhancement: Client-side encryption using SubtleCrypto API for additional zero-knowledge protection layer independent of OS security.
5. 👁️ Build Integrity: Supply Chain Assurance
Threats mitigated: Compromised build pipeline, tampered artifacts, unauthorized code injection.
Mechanisms: Automated CI/CD through GitHub Actions, SLSA Level 3 provenance attestations, immutable build artifacts, cryptographic signing of releases.
Validation: OpenSSF Scorecard monitoring (check current score), dependency review workflow, CodeQL security scanning.
Client-Side Threat Considerations
Client-side architecture shifts threat focus from server-side attacks to browser-based vulnerabilities, DOM manipulation risks, and local storage security.
Key security considerations for compliance tools:
- XSS Prevention: React framework provides automatic escaping. Additional DOMPurify sanitization for user-generated assessment notes. CSP headers enforce restrictive script policies.
- Data Confidentiality: Browser sandbox isolation plus OS-level encryption. Future roadmap includes client-side encryption for additional zero-knowledge protection.
- Supply Chain Security: SRI validation for external dependencies. Automated Dependabot updates. SLSA Level 3 build attestations provide provenance assurance.
- Storage Security: IndexedDB access restricted to same-origin. No server-side data transmission eliminates network interception risks.
- Build Pipeline Integrity: GitHub Actions automation with security scanning. CodeQL SAST analysis. Dependency review blocking vulnerable packages.
Threat modeling that honestly documents residual risk and architectural tradeoffs enables informed security decisions. Transparency about limitations builds trust more than marketing perfect security.
Supply Chain Security: Dependency Management
npm dependencies represent trust decisions. How verification works:
- License Compliance: FOSSA scanning ensures MIT/Apache-2.0/BSD compatibility. Public compliance badge provides transparency.
- Vulnerability Scanning: Dependabot automation generates security update PRs. GitHub dependency review workflow blocks vulnerable package introductions.
- Build Provenance: SLSA Level 3 attestations provide cryptographic evidence linking artifacts to source. View public attestations.
- Continuous Validation: OpenSSF Scorecard measures security practices. Check current score for branch protection, code review, and dependency update evidence.
- Static Analysis: CodeQL security scanning integrated into CI/CD. ESLint rules enforce secure coding patterns.
Dependency minimization strategy: Prefer platform APIs over libraries where practical. React core provides substantial functionality reducing external dependency requirements.
Security Roadmap: Progressive Enhancement
Security evolution planned through progressive enhancement maintaining backward compatibility while adding defense layers.
Phase 1: Enhanced Authentication
Optional OAuth integration for multi-device sync. GitHub/Google/Microsoft identity providers. Session management with secure token handling.
Phase 2: Client-Side Encryption
SubtleCrypto API integration for zero-knowledge architecture. AES-GCM encryption of assessment data. User-controlled encryption keys never transmitted.
Year 3: Audit Logging
Action log in IndexedDB. Merkle tree tamper-evidence.
Year 4: WebAuthn Biometric
Touch ID, Face ID, Windows Hello. Phishing-resistant.
Year 5: Post-Quantum Crypto
Lattice-based encryption. Quantum-resistant future-proofing.
Security Wisdom: Five Key Lessons
- Client-side = defensive advantage. No server = no server vulnerabilities.
- Six STRIDE categories → five defenses. Pattern recognition enabling focus.
- Type safety is security. Compile-time verification = pre-deployment bug elimination.
- Automated evidence > manual assurance. Cryptographic proof, not promises.
- Security roadmaps enable transparency. Show trajectory, not just snapshot.
Verify Our Security
Simon Moon, System Architect, Hack23 AB
"Client-side security is mathematical security—attack surface minimized through architectural constraint."