In the fast-moving world of web development, building secure applications is more than just fixing bugs or running vulnerability scans at the end. It is about starting with security in mind from the very beginning, especially during the architecture phase.
As an application security engineer, one of the most effective practices you can follow is conducting application security architecture reviews (ASARs). In this article, I’ll walk you through an updated and practical approach to performing these reviews in today’s environment, from traditional concerns like authentication to modern needs like cloud, containers, and DevSecOps pipelines.
An architecture review is a method to examine the security posture of an application design before it’s developed or deployed. The goal is to identify flaws in logic, data flow, or configuration that could lead to vulnerabilities. It’s always better (and cheaper) to fix these during the design stage than after deployment.
Tip: The best time to perform this review is during the design or planning phase of the software development lifecycle (SDLC). However, even if the app is already live, a retrospective review is still valuable.
1. Application Architecture Documents
Start by collecting all design documents:
- High-level architecture diagrams
- Data flow diagrams (DFDs)
- Network topology
- Trust boundaries
- Third-party integrations
If these don’t exist, that’s a red flag in itself.
2. Threat Modeling (STRIDE or LINDDUN)
Threat modeling is your North Star. It helps you identify risks based on the application’s design and data flow. Use frameworks like;
- STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege)
- LINDDUN for privacy risks. Tools like Threat Dragon, IriusRisk, or Microsoft Threat Modeling Tool can help automate this process.
Let’s break down modern architecture concerns aligned with OWASP ASVS and real-world AppSec practices.
1. Authentication & Session Management
- Enforce multi-factor authentication (MFA)
- Use secure frameworks like OAuth 2.0 or OpenID Connect
- Ensure sessions expire on logout/inactivity
- Regenerate session IDs on login
- Use secure cookies (HttpOnly, Secure, SameSite)
2. Authorization
- Follow the principle of least privilege
- Use role-based access control (RBAC) or attribute-based access control (ABAC)
- Prevent IDOR (Insecure Direct Object References)
- Always check authorization server-side, not just on the UI
3. Input Validation & Output Encoding
- Whitelist inputs using a centralized validation library
- Sanitize all user input across all layers (frontend, backend, DB)
- Prevent injection attacks (SQLi, XSS, etc.) using ORM, parameterized queries
- Encode output properly to prevent XSS
4. Cryptography
- Never create custom crypto; use trusted libraries (e.g., OpenSSL, Bouncy Castle)
- Store secrets using secure vaults (e.g., AWS Secrets Manager, HashiCorp Vault)
- Rotate encryption keys regularly
- Use strong ciphers (AES-256, SHA-256) and TLS 1.2+
5. Configuration Management
- Ensure secure headers (CSP, X-Frame-Options, etc.)
- Block unnecessary ports and protocols (e.g., disable TRACE and PUT if unused)
- Avoid sensitive data in GET parameters or client-side storage
- Review .env files and config maps—no plaintext secrets!
6. Cloud & Infrastructure
- Use network segmentation (e.g., separate web/app/db layers)
- Apply IAM least-privilege roles
- Use WAFs, security groups, and firewall rules
- Audit Infrastructure-as-Code (IaC) using tools like Checkov, tfsec, or KICS
7. Container and Kubernetes Security
- Scan images with Trivy, Grype, or Anchore
- Use PodSecurityPolicies, network policies, and RBAC in Kubernetes
- Isolate workloads with namespaces and node selectors
- Avoid running containers as root
8. Logging & Monitoring
- Enable logging for key security events (login, data access, permission changes)
- Avoid logging sensitive data (passwords, tokens, PII)
- Use centralized logging with alerts (ELK stack, Splunk, Datadog)
- Ensure logs are immutable and access-controlled
9. Secure CI/CD
- Integrate tools like SAST, SCA, and DAST into your pipelines
- Enforce branch protection and code review policies
- Use secrets scanning tools like Gitleaks and TruffleHog
- Scan dependencies for CVEs (e.g., using Dependabot, Snyk, or OWASP Dependency-Check)
During your review, rate each issue using a risk model. This helps prioritize fixes and communicate effectively with stakeholders. Some widely used risk rating models are
Conclusion: Shift Left, But Stay Sharp
Architecture reviews are not just a checkbox. They’re your chance to catch the biggest design flaws before they become production vulnerabilities. As applications move to the cloud and become more complex, a traditional checklist is no longer enough.
So modernize your review. Add threat modeling, cloud context, DevSecOps awareness, and automation. Use the tips in this article to build a scalable, proactive, and real-world architecture review practice. Security starts with design, and as AppSec engineers, we must make that design secure from day one.
Happy AppSec 🦉