EC-Council · CASE-.NET
Certified Application Security Engineer .NET (CASE-.NET) Practice Test
Validates the ability to build secure .NET applications throughout the software development lifecycle, covering secure requirements gathering, input validation, authentication and authorization, cryptographic practices, error handling, session management, and security testing.
Exam Details
Questions
625
Duration
120 minutes
Passing Score
70%
Difficulty
AssociateLast Updated
Feb 2026
Certified Application Security Engineer .NET (CASE-.NET) Practice Exam Preparation
Use this CASE-.NET practice exam to prepare for Certified Application Security Engineer .NET (CASE-.NET) with realistic questions, detailed explanations, and focused study modes. The practice bank includes 625 questions for EC-Council CASE-.NET, so you can review the exam steadily instead of relying on one long cram session.
As you practice, pay extra attention to patterns in your missed answers. Start with short sessions to identify weak areas, then move into timed quizzes once your accuracy is consistent.
The explanations are especially useful when you want to connect exam wording to the responsibilities and scenarios described in the official certification guidance. Use the free preview first, then unlock the full question bank when you are ready to build a complete study routine.
Exam Overview
The Certified Application Security Engineer .NET (CASE .NET) is an application security certification offered by EC-Council that validates a software developer's ability to integrate security practices throughout every phase of the .NET software development lifecycle (SDLC). Developed in partnership with global application and software development experts, it tests critical security knowledge and skills spanning pre-deployment through post-deployment phases, with a focus on .NET-specific secure coding techniques including input validation, authentication and authorization mechanisms, cryptographic implementation, session management, and error handling.
The certification covers the full spectrum of SDLC security activities: from gathering secure requirements and designing secure architectures, to writing defensively coded .NET applications and performing security testing using both static (SAST) and dynamic (DAST) analysis methods. It addresses real-world threats and attack vectors targeting .NET web applications and teaches developers to build security in from the ground up rather than bolt it on after deployment. The exam is identified by exam code 312-95 and is recognized globally as a benchmark for application security competency in the Microsoft .NET ecosystem.
Who Should Take This Exam
CASE .NET is designed primarily for .NET developers with a minimum of two years of professional development or information security experience who want to formalize their application security expertise. It is equally relevant for application security engineers, security analysts, and security testers who work with .NET-based systems and need to demonstrate proficiency in secure SDLC practices.
The certification is also well-suited for software architects, DevSecOps practitioners, and anyone involved in designing, building, testing, managing, or protecting .NET applications — including web applications, mobile applications, and IoT solutions built on the .NET framework. Professionals transitioning from pure development roles into application security roles will find this certification particularly valuable for validating their security-oriented coding skills.
Prerequisites
There are no strict formal educational prerequisites, but EC-Council requires candidates to meet at least one of the following eligibility criteria before sitting for the exam: complete official EC-Council CASE training through an accredited training partner (ATC, iWeek, or iClass), be an active EC-Council Secure Programmer (ECSP) .NET or Java member in good standing, possess a minimum of two years of working experience in the information security or software development domain, or hold an equivalent industry certification such as GIAC GSSP-.NET or GSSP-Java. Candidates applying via the experience or equivalent-certification pathway must submit a USD $100 non-refundable application fee.
In terms of recommended knowledge, candidates should have hands-on familiarity with the .NET framework and C# or VB.NET development, a working understanding of web application architectures, and foundational knowledge of common vulnerability categories such as those defined by OWASP. Familiarity with basic cryptographic concepts, HTTP/HTTPS protocols, and software testing methodologies will also ease preparation for the exam domains.
Exam Format
The CASE .NET exam (312-95) consists of 50 multiple-choice questions and must be completed within 120 minutes. The passing score is 70%, meaning candidates must answer at least 35 questions correctly. The exam is delivered through the EC-Council exam portal and can be taken at authorized Prometric testing centers or, in eligible cases, via online proctored delivery.
All 50 questions are scored; no unscored or survey items have been publicly disclosed. The multiple-choice format tests both conceptual understanding and practical application of secure coding principles across the ten defined exam domains. Candidates who do not pass may retake the exam, subject to EC-Council's standard retake policies.
Skills Measured
- 1.Domain 1: Understanding Application Security, Threats, and Attacks — Covers the foundational concepts of application security, common attack surfaces, and the threat landscape targeting .NET applications, including OWASP Top 10 and .NET-specific vulnerabilities.
- 2.Domain 2: Security Requirements Gathering — Addresses how to identify and document security requirements during the planning phase of the SDLC, including abuse case modeling and threat modeling techniques.
- 3.Domain 3: Secure Application Design and Architecture — Focuses on security design principles such as least privilege, defense in depth, separation of duties, and secure architecture patterns applicable to .NET systems.
- 4.Domain 4: Secure Coding Practices for Input Validation — Covers techniques for validating, sanitizing, and encoding user-supplied data in .NET to prevent injection attacks, XSS, and related vulnerabilities.
- 5.Domain 5: Secure Coding Practices for Authentication and Authorization — Examines implementation of robust authentication mechanisms (including multi-factor authentication) and role-based/claims-based authorization in .NET applications.
- 6.Domain 6: Secure Coding Practices for Cryptography — Covers proper use of cryptographic APIs in the .NET framework, including symmetric/asymmetric encryption, hashing, digital signatures, and common cryptographic pitfalls to avoid.
- 7.Domain 7: Secure Coding Practices for Session Management — Addresses secure session token generation, storage, transmission, and invalidation in .NET web applications to prevent session hijacking and fixation attacks.
- 8.Domain 8: Secure Coding Practices for Error Handling — Focuses on implementing secure exception handling and logging in .NET, preventing information leakage through error messages while ensuring adequate audit trails.
- 9.Domain 9: Static and Dynamic Application Security Testing (SAST & DAST) — Covers security testing methodologies applied during and after development, including code review techniques, automated static analysis tools, and dynamic testing approaches for .NET applications.
- 10.Domain 10: Secure Deployment and Maintenance — Addresses security considerations for deploying .NET applications to production environments, patch management, security configuration hardening, and ongoing maintenance security practices.
Study Tips
- Download and study the official CASE .NET Exam Blueprint v1 from cert.eccouncil.org, as it defines the exact knowledge areas and provides the authoritative outline for all 10 exam domains.
- Use EC-Council's official iClass self-paced or instructor-led training course, which aligns directly with the exam objectives and includes the official courseware textbook covering all 10 domains in depth.
- Focus heavily on Domains 4 through 8 (input validation, authentication, cryptography, session management, and error handling), as these secure coding practice domains represent the core practical skills the exam emphasizes.
- Practice with hands-on .NET coding exercises for each domain — particularly implementing ASP.NET Core authentication middleware, the .NET cryptography namespace (System.Security.Cryptography), and ASP.NET data validation attributes — since the exam tests applied knowledge, not just theory.
- Review the OWASP .NET Security Cheat Sheet and the OWASP Top 10 as supplementary references, since many exam scenarios are grounded in real-world attack patterns that OWASP documents extensively.
- Allocate approximately two months of structured study time, spending at least two hours per day, and use a topic checklist based on the Blueprint to ensure full coverage before scheduling the exam.
- Take practice exams from reputable sources to familiarize yourself with the multiple-choice question style and identify knowledge gaps; focus follow-up study on domains where practice scores are weakest.
Career Benefits
Earning the CASE .NET certification positions professionals for roles such as Application Security Engineer, Secure Software Developer, Security Analyst, DevSecOps Engineer, and Application Security Tester — all of which are in strong demand as organizations increasingly require security expertise embedded within development teams rather than solely in separate security departments. The credential is recognized globally and is valued by employers across financial services, healthcare, government, and technology sectors where .NET remains a dominant development platform.
The CASE .NET complements other EC-Council certifications such as the CEH and CPENT by providing a developer-focused security credential, and it stacks well with Microsoft-specific certifications for professionals building careers in the Microsoft ecosystem. Certified professionals typically see enhanced earning potential relative to non-certified peers, and the credential supports long-term career growth by demonstrating a structured, SDLC-wide approach to application security that aligns with frameworks such as OWASP SAMM and NIST SSDF.
Sample Questions
5 sample questions with answers and explanations. Start a practice session to test yourself across all 625 questions.
Preview — answers shown1. An ASP.NET Core application implements authorization policies using custom requirements and handlers. The development team creates this authorization handler implementation: protected override Task HandleRequirementAsync(AuthorizationHandlerContext context, MinimumAgeRequirement requirement) { var dobClaim = context.User.FindFirst(ClaimTypes.DateOfBirth); if (dobClaim == null) { context.Fail(); return Task.CompletedTask; } var age = DateTime.Today.Year - Convert.ToDateTime(dobClaim.Value).Year; if (age >= requirement.MinimumAge) context.Succeed(requirement); return Task.CompletedTask; } What is the security flaw in this handler implementation? (Select one!)
AThe handler calls context.Fail() when the claim is missing which prevents other handlers from succeeding
BUsing DateTime.Today for age calculation is vulnerable to timezone manipulation attacks
CMissing authorization handlers should call context.Succeed() to maintain fail-open security
DThe handler does not validate the DateOfBirth claim format before converting to DateTime
Explanation
Calling context.Fail() explicitly fails the authorization even if other handlers could satisfy the requirement, creating a denial-of-service condition. Authorization handlers should only call context.Succeed() when requirements are met and simply return without calling Fail() when they cannot make a determination, allowing other handlers to evaluate. Timezone manipulation does not materially affect age-based authorization security. While input validation is good practice, Convert.ToDateTime handles most date formats safely. Fail-open security is incorrect as authorization should default to denying access.
2. A .NET development team uses NuGet package dependency scanning to identify vulnerable packages. The team configures NuGetAudit with NuGetAuditMode set to 'all' and NuGetAuditLevel set to 'low'. During the build, the following warnings appear: NU1901 (Low severity), NU1902 (Moderate severity), NU1903 (High severity). The team wants to fail the build only for high and critical severity vulnerabilities. Which configuration should be implemented? (Select one!)
AAdd WarningsAsErrors with NU1901, NU1902, NU1903, and NU1904
BSet NuGetAuditMode to 'direct' to scan only direct dependencies
CSet NuGetAuditLevel to 'high' and add TreatWarningsAsErrors for NU1903 and NU1904
DSet NuGetAuditLevel to 'moderate' and enable TreatWarningsAsErrors globally
Explanation
To fail the build only for high and critical severity vulnerabilities, the team should set NuGetAuditLevel to 'high' which will report only high (NU1903) and critical (NU1904) severity issues, filtering out low and moderate warnings. Additionally, TreatWarningsAsErrors should be configured specifically for NU1903 and NU1904 to convert these warnings into build-breaking errors. This approach ensures low (NU1901) and moderate (NU1902) vulnerabilities are not reported, while high and critical issues fail the build. Setting NuGetAuditLevel to 'moderate' would still include moderate severity warnings which the team wants to exclude. Enabling TreatWarningsAsErrors globally would break the build on all warnings including non-security issues. Setting NuGetAuditMode to 'direct' changes what dependencies are scanned (direct vs transitive) but does not control severity filtering. Adding all NU warning codes to WarningsAsErrors would fail the build on low and moderate severities, which contradicts the requirement.
3. An API implements rate limiting using the FixedWindowLimiter with PermitLimit=100 and Window=1 minute. During load testing, the team observes that clients can send 200 requests in the first 30 seconds of each minute without being throttled. What explains this behavior? (Select one!)
AThe configuration is incorrect and should use TokenBucketLimiter instead
BRate limiting is applied per endpoint, not globally, allowing double the limit
CFixedWindowLimiter allows burst traffic at window boundaries because windows reset at fixed intervals regardless of request timing
DThe PermitLimit value is doubled internally for the first window
Explanation
FixedWindowLimiter has a known edge case where clients can send up to twice the permit limit by sending requests at the end of one window and the beginning of the next. Windows reset at fixed clock intervals (every minute at :00 seconds), not sliding with requests. TokenBucketLimiter prevents bursts through token accumulation but does not explain the observed behavior. Rate limiting is applied per limiter policy configuration. PermitLimit is not doubled.
4. A security assessment evaluates XML parsing implementation for processing user-uploaded configuration files. The application uses XmlDocument to parse files. Which configuration prevents XML External Entity attacks? (Select one!)
Avar doc = new XmlDocument() { XmlResolver = new XmlUrlResolver() }; doc.Load(xmlStream);
Bvar settings = new XmlReaderSettings { DtdProcessing = DtdProcessing.Parse }; var reader = XmlReader.Create(xmlStream, settings);
Cvar doc = new XmlDocument() { XmlResolver = null }; doc.LoadXml(xmlContent);
Dvar doc = new XmlDocument(); doc.Load(xmlStream);
Explanation
Setting XmlResolver to null prevents external entity resolution, blocking XXE attacks by disabling the ability to load external resources referenced in XML documents. Default XmlDocument configuration in older .NET Framework versions is vulnerable to XXE. XmlUrlResolver explicitly enables external entity loading, creating XXE vulnerabilities. DtdProcessing.Parse allows DTD processing which enables entity expansion attacks. The null resolver approach is the most direct and secure mitigation for XXE in XmlDocument scenarios.
5. A .NET 6 project enables NuGetAudit with the following configuration: NuGetAudit set to true, NuGetAuditMode set to all, NuGetAuditLevel set to low, and TreatWarningsAsErrors includes NU1903 and NU1904. During build, the project fails with error NU1903. What severity level of vulnerability caused the build failure? (Select one!)
ACritical severity (NU1904)
BLow severity (NU1901)
CModerate severity (NU1902)
DHigh severity (NU1903)
Explanation
NU1903 represents high severity vulnerabilities in NuGet packages. The build failed because TreatWarningsAsErrors includes NU1903, causing high severity vulnerability warnings to be treated as errors that fail the build. The NuGet audit warning codes map as follows: NU1901 for low severity, NU1902 for moderate severity, NU1903 for high severity, and NU1904 for critical severity. Since the error code is specifically NU1903, the vulnerability severity is high. Critical severity would generate NU1904, not NU1903.
More EC-Council Practice Exams
Certified Threat Intelligence Analyst (CTIA)
CTIA · 740 questions
Certified Cybersecurity Technician (CCT)
CCT · 630 questions
Certified Secure Computer User (CSCU)
CSCU · 630 questions
EC-Council Certified Encryption Specialist (ECES)
ECES · 627 questions
Ethical Hacking Essentials (EHE)
EHE · 627 questions
ICS/SCADA Cybersecurity
ICS-SCADA · 627 questions
$17.99
One-time access to this exam
Full access to all 625 questions
Or $15/mo for all 253 exams
Detailed explanations
Free preview stays available