- What the 11 Content Areas Actually Are
- How to Read an Unweighted Outline
- Domains 1-2: Mindset, Threat Modeling and Secure Foundations
- Domains 3-4: Authentication, Sessions and Access Control
- Domains 5-6: Input Validation and Data Handling
- Domains 7-8: Monitoring and Deployment
- Domains 9-10: CI/CD, Supply Chain and Incident Response
- Domain 11: OWASP Top 10 as a Mapping Exercise
- Exam Mechanics That Affect How You Study
- Sequencing the Domains Across Your Prep
- Frequently Asked Questions
- Mile2's public course outline lists 11 unweighted modules for the Certified Secure Web Application Engineer; no percentage blueprint was verified.
- The assessment uses 100 multiple-choice items under Mile2's general policy, but the exact timer and passing score remain unverified.
- Domain 11 maps the OWASP Top 10 to practice, so treat it as a synthesis of Domains 1-10.
- Confirm supervision rules before booking: Mile2's FAQ and policy document describe administration differently.
What the 11 Content Areas Actually Are
The Certified Secure Web Application Engineer credential is issued by Mile2 Cybersecurity Institute. The 11 content areas in this guide come directly from the detailed module list in Mile2's public course outline (modules 01 through 11). They are the issuer's preparation curriculum headings, and they are the best publicly verifiable map of what a candidate should be ready to discuss.
It is worth being precise about what that means. These are preparation topics, not a published exam blueprint. Mile2 has not, in the public material reviewed, declared that the exam is divided into exactly 11 weighted domains, and it does not promise that the outline exhaustively covers every question. Treat the list as a curriculum spine: if you can explain each area in practical, engineering terms, you are preparing in the right direction.
If you are new to the credential itself, the explainer on what C)SWAE certification is covers the basics, and the C)SWAE requirements guide covers eligibility and suggested background.
| # | Content Area | Core Engineering Theme |
|---|---|---|
| 1 | Security Mindset, Risk, and Threat Modeling | Thinking like an attacker and prioritizing risk |
| 2 | Secure Foundations: Architecture, Transport, and Headers | Baseline design, TLS and browser-side protections |
| 3 | Authentication and Session Security | Proving identity and protecting session state |
| 4 | Authorization and Access Control | Enforcing what an identity may do |
| 5 | Secure Input and Data Validation | Treating all input as untrusted |
| 6 | Secure Data Handling and Storage | Protecting data at rest and in use |
| 7 | Monitoring, Detection, and Logging | Seeing attacks as they happen |
| 8 | Secure Deployment and Configuration Management | Hardened, repeatable environments |
| 9 | Secure CI/CD and Supply Chain Security | Trustworthy build pipelines and dependencies |
| 10 | Incident Response and Recovery for Web Applications | Containing and recovering from compromise |
| 11 | OWASP Top 10: Mapping Risk to Practice | Connecting named risks to concrete controls |
How to Read an Unweighted Outline
Many candidates want to know which domain carries the most exam weight. For this credential, no public percentage-weighted blueprint and no highest-weighted topic were verified, so any claim about "the most heavily tested domain" would be speculation. The sensible response is to prepare evenly, then adjust based on your own weak spots revealed by practice questions.
A useful approach is to ask of every domain: what would an engineer actually do? The credential name says "Engineer," and the curriculum headings are action-oriented (architecture, validation, deployment, recovery). Expect scenario-flavored multiple-choice questions where you choose the most appropriate control, not trivia recall. For a realistic read on difficulty, see how hard the C)SWAE exam is.
Domains 1-2: Mindset, Threat Modeling and Secure Foundations
Domain 1: Security Mindset, Risk, and Threat Modeling
This is the conceptual entry point. You should be able to reason about assets, attackers, trust boundaries and the likelihood and impact of misuse before any code is written.
- Identifying assets, entry points and trust boundaries in a web application
- Structured threat modeling, including categorizing threats and mapping them to mitigations
- Risk ranking: deciding which findings to fix first and why
- The case for building security in early rather than patching late
Questions here tend to test judgment. A typical item might describe a feature and ask which threat is most relevant or which design change reduces risk most cheaply. Practice articulating trade-offs, not just definitions.
Domain 2: Secure Foundations: Architecture, Transport, and Headers
This area covers the baseline every web application needs before feature-level controls matter.
- Secure architectural patterns: layering, least privilege between components, minimizing attack surface
- Transport security: why TLS matters, certificate handling and avoiding downgrade or mixed-content weaknesses
- Security-relevant HTTP response headers and what each one mitigates (for example, framing, content-type sniffing, script execution policy and transport enforcement)
- Cookie attributes and browser-enforced protections
Know the purpose of each header well enough to pick the right one for a described problem. Memorizing names without understanding the attack each prevents is a common trap.
Domains 3-4: Authentication, Sessions and Access Control
These two domains are closely related but distinct, and the exam may test whether you can tell them apart. Authentication establishes who you are; authorization decides what you may do.
Domain 3: Authentication and Session Security
Focus on how identity is proven and how the resulting session is protected over its lifetime.
- Credential handling, password storage principles and resistance to brute-force and credential-stuffing attempts
- Multi-factor authentication concepts and recovery-flow weaknesses
- Session identifier generation, rotation after login, expiry and invalidation on logout
- Session attacks: fixation, hijacking and cross-site request forgery, with their defenses
Domain 4: Authorization and Access Control
Here the emphasis is on enforcing permissions correctly and consistently on the server side.
- Role-based and attribute-based access control models and when each fits
- Broken object-level and function-level authorization, including insecure direct object references
- Privilege escalation, both vertical and horizontal
- Deny-by-default design and centralized enforcement rather than scattered checks
Domains 5-6: Input Validation and Data Handling
Domain 5: Secure Input and Data Validation
This is the home of the classic injection family and a core engineering skill: never trust data crossing a trust boundary.
- Allow-list validation versus block-list approaches, and why allow-lists are preferred
- Injection classes: SQL, command, template and cross-site scripting, with context-appropriate output encoding
- Parameterized queries and safe APIs as the primary defense
- File upload risks, deserialization hazards and server-side request forgery
Be ready to choose the correct defense for a given context. Output encoding for HTML differs from escaping for a JavaScript or URL context, and a question may hinge on that nuance.
Domain 6: Secure Data Handling and Storage
This domain addresses what happens to sensitive data once the application accepts it.
- Classifying data and applying protections proportional to sensitivity
- Encryption at rest and in transit, and the basics of key management
- Hashing versus encryption, and appropriate use of each
- Minimizing retention, masking sensitive fields and avoiding secrets in source code or logs
Domains 7-8: Monitoring and Deployment
Domain 7: Monitoring, Detection, and Logging
Prevention fails eventually, so you must be able to detect abuse. This domain treats logging as a security control.
- What to log: authentication events, access-control failures, input-validation failures and administrative actions
- What never to log: credentials, tokens and sensitive personal data
- Log integrity, centralization and protection against tampering or injection into logs
- Alerting on suspicious patterns and the role of web application firewalls as a detective and protective layer
Domain 8: Secure Deployment and Configuration Management
A well-written application can still be exposed by a careless environment.
- Hardening servers, frameworks and containers; removing default accounts, sample content and debug modes
- Separating environments and managing secrets outside the codebase
- Configuration drift, baselines and repeatable, auditable configuration
- Patch and update processes for the runtime stack
Domains 9-10: CI/CD, Supply Chain and Incident Response
Domain 9: Secure CI/CD and Supply Chain Security
Modern web applications are assembled from third-party components and shipped through automated pipelines, which creates its own attack surface.
- Securing build systems, pipeline credentials and artifact integrity
- Dependency risk: vulnerable or malicious packages, version pinning and software composition analysis
- Integrating static and dynamic testing into the pipeline
- Code review, signing and controlling who can promote changes to production
Domain 10: Incident Response and Recovery for Web Applications
This domain asks what you do when something goes wrong, adapted to the web application context.
- The incident lifecycle: preparation, detection, containment, eradication and recovery
- Preserving evidence and using logs to reconstruct what happened
- Credential and session revocation, patching the root cause and restoring from known-good state
- Post-incident review and feeding lessons back into design and testing
Domains 7 and 10 reinforce each other: good logging makes response possible, and response exercises reveal logging gaps. Study them as a pair.
Domain 11: OWASP Top 10 as a Mapping Exercise
The final area, OWASP Top 10: Mapping Risk to Practice, is best understood as a synthesis layer. The named risk categories are not new material; they are a vocabulary for organizing what you learned in Domains 1 through 10. Broken access control belongs with Domain 4, injection with Domain 5, cryptographic failures with Domain 6, vulnerable components with Domain 9, and logging failures with Domain 7.
Key Takeaway
Build your own two-column table: each OWASP risk category on the left, the control and the domain that addresses it on the right. If you can fill it from memory, Domain 11 is largely done, and you have also reviewed most of the curriculum.
Because list editions change over time, focus on understanding each risk category and its defense rather than memorizing rank positions. For a compact review format once you have built the mapping, the C)SWAE cheat sheet is a useful companion.
Exam Mechanics That Affect How You Study
Mile2's general policy document describes an assessment of 100 multiple-choice items, and that rule is not one of the exclusions for this credential. Delivery is online through your Mile2 account and learning management system. That is the extent of what is firmly established, and it is worth being honest about the gaps.
- Timer and passing score: the course PDF's exam paragraph names a different Mile2 certification, so its timing and score statements are not assigned to this exam. Verify both directly with Mile2 before test day. Our passing score guide tracks what is and is not confirmed.
- Supervision and resources: the FAQ describes most standard exams as on-demand without a live-proctor appointment, while the policy document describes proctored, open-book assessment with advance scheduling. Confirm which applies to your assigned exam and what resources are permitted. See the exam dates and scheduling guide.
- Bundle: the public C)SWAE Exam Combo lists the exam, a simulator and a prep guide, with two attempts per the FAQ. A current checkout price was not verified here; the certification cost breakdown explains the pricing caveats.
- Training is optional: Mile2 training is not mandatory. The live English course runs five days and advertises 40 CEUs, but course hours do not establish an exam timer. Suggested background includes networking knowledge, at least one coding language, Linux and open-shell familiarity, or 24 months of software and security experience.
The exam is valid for three years. Renewal is through documented CEUs (60 over three years under the standard route) plus a renewal purchase and ethics acknowledgment, or through alternative paths such as passing the latest existing-credential exam. Mile2's own documents differ somewhat on how annual CEU requirements interact with renewal, so confirm the route and deadline for your credential specifically.
Sequencing the Domains Across Your Prep
You do not need to study the domains in numerical order. The following sequence groups related material so each week builds on the last. Adjust the pace to your background; developers may move quickly through Domains 5 and 9, while operations-oriented candidates may do the opposite. A broader plan is in the C)SWAE study guide.
Concepts and Baselines (Domains 1-2)
- Practice threat-modeling a simple login-and-profile application
- List each security header and the attack it mitigates
Identity and Permissions (Domains 3-4)
- Walk through the full session lifecycle and its failure modes
- Write examples of horizontal and vertical privilege escalation
Data Paths (Domains 5-6)
- Match each injection type to its correct defense and context
- Distinguish hashing, encryption and key management use cases
Operations and Pipeline (Domains 7-10)
- Define a minimum logging set and an incident response checklist
- Review pipeline and dependency risks
Synthesis and Practice (Domain 11)
- Complete your OWASP-to-domain mapping table
- Take timed practice sets from the C)SWAE practice test and review every miss
Practice questions are most useful for finding which domains you misjudge, not for memorizing answers. If a miss traces back to confusing two concepts, return to that domain's engineering reasoning. Reviewing the pass rate discussion is also worthwhile, mainly for understanding why no verified figure should be assumed.
Frequently Asked Questions
No weighted blueprint was verified in Mile2's public material. The 11 areas are curriculum headings from the course outline, so prepare across all of them rather than betting on a single heavy domain.
Mile2's policy document describes 100 multiple-choice items for its assessments, and this credential is not among the exclusions. The exact timer and passing threshold are not confirmed here, so check them with Mile2 before scheduling.
No. Mile2 training is not mandatory. Suggested preparation includes networking knowledge, at least one coding language, Linux familiarity, or roughly 24 months of software and security experience.
Start with Domain 1, Security Mindset, Risk, and Threat Modeling, because it supplies the reasoning framework for the rest. Save Domain 11 for last, since it maps OWASP risks onto everything else.
It is valid for three years. Renewal typically involves 60 documented CEUs over that period, a renewal purchase and an ethics acknowledgment, or alternative paths Mile2 publishes. Confirm your credential-specific deadline directly with Mile2.