EC-Council • CASE-.NET
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.
Questions
625
Duration
120 minutes
Passing Score
70%
Difficulty
AssociateLast Updated
Feb 2026
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.
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.
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.
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.
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.
5 sample questions with correct answers and explanations. Start a practice session to test yourself across all 625 questions.
1. An ASP.NET Core API serves a Single Page Application (SPA) built with Angular. The API must implement CSRF protection that works with the SPA architecture. Which approach correctly implements the double-submit cookie pattern for Angular? (Select one!)
Explanation
The Angular CSRF protection pattern requires the server to set a cookie named XSRF-TOKEN with HttpOnly=false so JavaScript can read it. Angular's HttpClient automatically reads this cookie and sends its value in the X-XSRF-TOKEN request header. The server validates that both values match. HttpOnly cookies cannot be read by JavaScript, breaking the pattern. The @Html.AntiForgeryToken() helper is for server-rendered Razor views, not SPAs. Storing tokens in localStorage is vulnerable to XSS attacks and does not follow the double-submit cookie pattern. The correct implementation uses response.Cookies.Append with HttpOnly=false specifically for the XSRF-TOKEN cookie.
2. A development team implements content security policy headers: `context.Response.Headers.Add("Content-Security-Policy", "default-src 'self'; script-src 'unsafe-inline'");`. What security vulnerability does this configuration introduce? (Select one!)
Explanation
Content Security Policy's primary purpose is preventing XSS attacks by controlling script execution. The 'unsafe-inline' directive completely undermines this protection by allowing all inline scripts including attacker-injected <script> tags and event handlers (onclick, onerror, etc.). This makes CSP ineffective against XSS. The secure approach is removing 'unsafe-inline' and using nonces or hashes for necessary inline scripts, or moving all JavaScript to external files. While default-src 'self' does restrict external resources, this is intentional security and CDNs should be explicitly allowed if needed. Missing style-src falls back to default-src. frame-ancestors is a separate concern addressed by frame-ancestors directive not script-src.
3. An organization implements the OCTAVE methodology for security risk assessment. The methodology divides the assessment into three phases. Which statement correctly describes these phases in order? (Select one!)
Explanation
OCTAVE specifically defines three phases: organizational view focuses on critical assets and business processes from an organizational perspective, technological view examines infrastructure and identifies technical vulnerabilities, and strategy development phase creates risk mitigation strategies and action plans. The other options describe generic security processes but not OCTAVE's specific three-phase structure.
4. During the design phase of a new ASP.NET Core banking application, the security team performs threat modeling using STRIDE methodology. They identify that an attacker could modify transaction amounts in POST requests between the client browser and server. Which STRIDE category does this threat represent? (Select one!)
Explanation
Tampering represents threats where an attacker modifies data in transit or at rest, violating data integrity. Modifying transaction amounts in HTTP requests is a classic tampering attack. Spoofing involves impersonating another user or system and violates authentication. Repudiation involves denying actions that were performed, violating non-repudiation. Information Disclosure involves unauthorized access to confidential data, violating confidentiality. This scenario specifically describes data modification, which is the core characteristic of tampering threats.
5. A development team enables NuGet package vulnerability auditing in a .NET 8 project by setting <NuGetAudit>true</NuGetAudit> in the project file. After running dotnet restore, the build succeeds without warnings despite using packages with known CVEs. Investigation reveals that the project references a package with a NU1903 (high severity) vulnerability. Which configuration change forces build failure for high-severity vulnerabilities? (Select one!)
Explanation
NuGet audit warnings use specific codes: NU1901 (low), NU1902 (moderate), NU1903 (high), and NU1904 (critical). By default, these are warnings that do not fail the build. Setting <TreatWarningsAsErrors>NU1903;NU1904</TreatWarningsAsErrors> elevates high and critical severity warnings to errors, causing build failure. This enforces a security policy preventing deployment of code with high-severity vulnerabilities. NuGetAuditMode controls whether direct and transitive dependencies are checked (default: direct only; all: includes transitive). NuGetAuditLevel sets the minimum severity to report (default: low). These control visibility but do not fail builds. There is no <NuGetAuditFailOnWarnings> configuration property in MSBuild/NuGet. The --no-cache parameter bypasses the NuGet cache during restore but does not affect warning/error behavior. The complete configuration for strict vulnerability enforcement is: <NuGetAudit>true</NuGetAudit>, <NuGetAuditMode>all</NuGetAuditMode>, <NuGetAuditLevel>low</NuGetAuditLevel>, <TreatWarningsAsErrors>NU1903;NU1904</TreatWarningsAsErrors>.
One-time access to this exam