Chapter 29: Improving your application’s security

Introduction

This chapter introduces common web-application threats and the ASP.NET Core protections and practices used to reduce them, with HTTPS as the essential foundation.

• Security threat landscape: Describe the chapter’s security focus: making developers aware of common application vulnerabilities, how attackers can exploit them, and the need to recognize potential flaws as an application evolves.
  Why it matters: Recognizing likely vulnerabilities is the first step toward not introducing them into an application.
• HTTPS security foundation: Explain why HTTPS should be added before the other safeguards: it encrypts traffic between users’ browsers and the application, and without it attackers could undermine many additional protections.
  Why it matters: HTTPS protects traffic in transit and provides the foundation on which the chapter’s other defenses rely.
• Chapter security roadmap: Outline the chapter’s main topics: XSS and CSRF defenses, CORS for browser JavaScript calls to an API in another app, and additional threats including SQL injection and other application flaws.
  Why it matters: This roadmap helps you connect each later section to the particular security risk it addresses.

Key terms: vulnerabilities, attackers, security practices, HTTPS, encrypt, traffic, cross-site scripting, XSS, cross-site request forgery, CSRF

29.1 Defending against cross-site scripting (XSS) attacks

This section explains how XSS attacks arise from unsafe rendering of user-controlled content and how Razor encoding and context-appropriate output practices prevent them.

• XSS attack mechanism: Explain how an attacker can submit malicious content through a legitimate input path and have it rendered into pages viewed by other users, causing arbitrary JavaScript to execute in their browsers. State that this can let an attacker steal cookies, impersonate users, or otherwise act in the compromised browser.
  Why it matters: Understanding the path from stored input to executed script helps you recognize where an XSS vulnerability can occur.
• Razor HTML encoding protection: Describe that Razor HTML-encodes data rendered with Tag Helpers, HTML Helpers, and the @ syntax by default, so markup such as a script tag is displayed as text rather than added to the HTML DOM. Explain why @Html.Raw() is dangerous when its HTML can contain user input, directly or indirectly, and why output encoding should still be used even if input validation is strict.
  Why it matters: Razor's default encoding is a major defense, but bypassing it for user-influenced content can immediately create an XSS vulnerability.
• Context-specific output encoding: Distinguish HTML encoding from JavaScript encoding when server values are inserted into a Razor page. Describe why an HTML-encoded value placed directly in JavaScript can produce incorrect results, why JavaScriptEncoder encodes JavaScript-context characters such as quotes safely, and why the recommended approach is to write values to HTML attributes and read them from JavaScript instead.
  Why it matters: Encoding must match the output context, or values can be unsafe or behave incorrectly despite having been encoded.

Key terms: cross-site scripting, XSS, arbitrary JavaScript, user input, Document Object Model, DOM, HTML encoding, Razor, Tag Helpers, HTML Helpers

29.2 Protecting from cross-site request forgery (CSRF) attacks

This section explains how cookie-authenticated applications are vulnerable to CSRF and how ASP.NET Core antiforgery tokens, data protection keys, and framework-specific validation mitigate that risk.

• CSRF attack mechanism: Explain how a malicious site can make a state-changing request as a logged-in user when the target application uses cookie authentication. Describe why the browser automatically attaching the target site's cookies makes a forged form POST appear authenticated.
  Why it matters: Recognizing that authentication cookies are sent automatically helps you identify where an attacker can impersonate a user.
• Antiforgery token validation: Describe the synchronizer token pattern used by ASP.NET Core antiforgery protection: one user-specific token is sent in a cookie and another in the protected form. Explain that the server rejects a dangerous request when either token is missing or their values do not match.
  Why it matters: Antiforgery validation adds proof that a state-changing request originated from your application rather than an attacker-controlled form.
• Framework antiforgery behavior: Distinguish the default antiforgery behavior of Razor Pages from MVC controllers with views. State that the Form Tag Helper renders tokens, Razor Pages validates dangerous requests automatically, and MVC controllers require [ValidateAntiForgeryToken] on vulnerable controllers or actions.
  Why it matters: Knowing the framework defaults prevents accidentally leaving MVC form-handling actions exposed to CSRF.
• Dangerous request protection scope: Explain why antiforgery validation is intended for state-changing methods such as POST and DELETE rather than GET. Describe the related limitation that CSRF is a cookie-authentication problem: applications authenticating with tokens sent in request headers are not vulnerable in the same way, and JSON API requests may carry an antiforgery token in a header instead of form data.
  Why it matters: Applying antiforgery checks to the right requests preserves normal safe reads while protecting operations that can change data.
• Data protection key sharing: Describe how ASP.NET Core data protection APIs create the encrypted antiforgery tokens and authentication cookies using protected key files. Explain why servers in a web farm need a shared, securely stored key location so every server can decrypt cookies and tokens created by another server.
  Why it matters: Securely sharing data-protection keys is necessary for consistent authentication and antiforgery behavior across multiple application servers.

Key terms: cross-site request forgery, CSRF, cookie authentication, authenticated request, form POST, synchronizer token pattern, antiforgery token, cookie token, __RequestVerificationToken, hidden field

29.3 Calling your web APIs from other domains using CORS

This section introduces the browser same-origin policy and explains how CORS safely permits JavaScript clients on approved origins to call an API on another origin.

• Same-origin policy: Explain how the browser's same-origin policy restricts JavaScript requests to resources with an identical scheme, domain, and port. Distinguish an origin from a URL path and describe why a change to any of those three origin components makes a request cross-origin.
  Why it matters: The same-origin policy is the browser protection that prevents one website's JavaScript from freely reading resources from another site.
• CORS for approved API access: Describe CORS as a web standard that lets an API explicitly allow JavaScript applications from another origin to make requests. Explain that it enables cross-origin scenarios, such as a web app calling a separately hosted API, while allowing the API to control which applications may call it.
  Why it matters: CORS enables common separately hosted frontend and API designs without removing the browser's cross-origin protection for every site.

Key terms: same-origin policy, origin, scheme, domain, port, cross-origin request, cross-origin resource sharing, CORS, CORS headers, web API

29.3.1 Understanding CORS and how it works

This section explains how CORS policies use response headers and browser preflight checks to control which cross-origin web API requests are permitted.

• CORS policy permissions: Describe the kinds of cross-origin access rules a CORS policy can express, including allowed origins, HTTP methods, response headers, and credentials. Explain that policies can be applied across an application or differently to individual API endpoints.
  Why it matters: A CORS policy lets an API grant only the external browser access it intends to allow.
• CORS response header protocol: Explain that an API communicates its CORS decisions by placing special HTTP headers on responses, stating which origins, methods, and headers are allowed. Describe that the browser uses those headers to decide whether browser code may use a cross-origin response.
  Why it matters: CORS is enforced through the browser's interpretation of API response headers, not merely by a server-side access rule.
• Preflight request sequence: Trace the CORS preflight sequence: for some requests, the browser first sends an OPTIONS request to check permission, and sends the actual cross-origin request only when the API returns the required CORS headers.
  Why it matters: Understanding preflight explains why an API can receive an OPTIONS request before the request an application intended to make.

Key terms: CORS, cross-origin requests, policy, origins, HTTP verbs, credentials, CORS headers, HTTP headers, response, preflight request

29.3.2 Adding a global CORS policy to your whole app

This section shows how to configure and apply a named CORS policy globally so a specified web application can call an API hosted on another origin.

• CORS adoption boundaries: Explain why CORS should be enabled only when an API genuinely needs to serve a client hosted on another domain, and identify that CORS is configured on the API being called rather than on the client application making the request.
  Why it matters: Restricting CORS avoids unnecessarily reopening a browser security boundary for every API consumer.
• Named CORS policy configuration: Describe how to register CORS services with AddCors() and define a named policy, such as AllowShoppingApp, that permits a specific origin to call the API. State that a policy controls allowed origins, response headers, and HTTP methods, and that allowing all methods is needed when methods beyond the simple GET, HEAD, and POST methods are required.
  Why it matters: A narrowly defined policy lets the intended frontend access the API without granting the same access to every origin.
• Global CORS middleware placement: Describe how to apply a named CORS policy to the whole application with UseCors() in the middleware pipeline. Explain that UseCors() must run after UseRouting() so it can handle preflight requests and add CORS response headers, and that it is commonly placed before UseAuthentication().
  Why it matters: Correct middleware placement ensures browsers receive the preflight responses and headers required to expose an API response to client-side JavaScript.

Key terms: CORS, cross-origin requests, API, origin, AddCors(), CORS policy, AllowShoppingApp, WithOrigins(), http://shopping.com, http://api.shopping.com

29.3.3 Adding CORS to specific endpoints with EnableCors metadata

This section shows how to apply named CORS policies selectively to endpoints, route groups, controllers, and actions instead of enabling CORS for an entire application.

• Endpoint-specific CORS protection: Explain why an application should enable CORS only on the endpoints that require cross-origin access when only a subset of its actions needs it. Describe how separate named policies can permit different origins or HTTP verbs for different parts of an API.
  Why it matters: Restricting CORS to the endpoints that need it reduces the cross-origin attack surface of an application.
• CORS endpoint policy application: Describe how to attach a named CORS policy to minimal API endpoints or route groups with RequireCors(), and to MVC controllers or action methods with the [EnableCors] attribute. State that [DisableCors] disables cross-origin access for an endpoint.
  Why it matters: These APIs let you express precisely which application endpoints accept requests from other origins.
• CORS metadata and middleware order: Explain that RequireCors() and [EnableCors] add CORS metadata to an endpoint, which CorsMiddleware reads to choose the applicable policy. State that CorsMiddleware must run after RoutingMiddleware so that routing has selected the endpoint first.
  Why it matters: Correct middleware ordering is necessary for ASP.NET Core to discover an endpoint's CORS policy.
• Default and endpoint policy interaction: Describe the recommended choice between a single application-wide default CORS policy and endpoint-specific policies: use UseCors() without a default policy when selecting policies per endpoint, and avoid mixing default and individual policies because both apply and can be confusing.
  Why it matters: Choosing one CORS policy strategy avoids unexpected combined policy behavior.

Key terms: CORS, cross-origin requests, CORS policy, AddCors, AddPolicy, RequireCors(), [EnableCors], [DisableCors], route group, controller

29.3.4 Configuring CORS policies

This section explains how to configure a least-permissive CORS policy and why cross-origin requests should be avoided unless they are necessary.

• CORS policy controls: Describe the aspects of a cross-origin request that a CORS policy can control: permitted origins, HTTP verbs, request headers, readable response headers, and whether credentials are sent.
  Why it matters: Restricting each of these dimensions limits what another origin can do with your API.
• Least-permissive CORS configuration: Explain the recommended approach to configuring CORS: first confirm that cross-origin access is genuinely required, start by allowing required origins with WithOrigins(), and then expand or restrict the policy only as necessary.
  Why it matters: A narrowly scoped policy preserves browser security protections while still enabling the functionality your application needs.
• Avoiding cross-origin complexity: Explain why the section recommends avoiding cross-origin requests where possible, including avoiding HTTP-to-HTTPS cross-domain issues by running applications behind HTTPS; alternatively, CORS can be configured in a reverse proxy or application gateway.
  Why it matters: Avoiding unnecessary cross-origin traffic reduces browser-specific behavior and CORS troubleshooting problems.

Key terms: CORS policy, CorsPolicyBuilder, origins, HTTP verbs, headers, response headers, WithOrigins(), cross-origin requests, cross-origin lockdown, HTTP to HTTPS

29.4 Exploring other attack vectors

This introduction situates XSS and CSRF among OWASP’s critical web-app risks and previews additional common vulnerabilities covered next.

• Common vulnerability roadmap: Describe that XSS and CSRF are important, commonly recognized web-application vulnerabilities, and state that the following subsections introduce other common attack vectors and ways to avoid them.
  Why it matters: Recognizing that security involves multiple attack vectors helps you look beyond only XSS and CSRF when protecting an application.

Key terms: XSS, CSRF, OWASP top ten, attack vectors

29.4.1 Detecting and avoiding open redirect attacks

This section explains how unvalidated user-supplied redirect URLs enable open redirect attacks and how to safely restrict redirects to trusted destinations.

• Open redirect attack flow: Explain how an open redirect attack exploits a returnUrl parameter, from a user following a seemingly safe application link through login to being sent to an attacker-controlled site.
  Why it matters: An attacker can use your trusted application URL to lead users to malware or other malicious content.
• Safe return URL validation: Describe how to prevent open redirects by validating that a user-supplied return URL is local before redirecting, using Url.IsLocalUrl() with a safe fallback or LocalRedirect() to reject nonlocal URLs.
  Why it matters: Checking redirect targets prevents your application from being used as a trusted route to malicious external content.
• Registered external redirect destinations: State why local-only validation cannot be used for authentication flows such as OpenID Connect that must redirect externally, and describe redirecting only to URLs registered in advance instead.
  Why it matters: When an external redirect is necessary, an allowlist of preregistered destinations provides the needed trust boundary.

Key terms: open redirect attack, returnUrl, query string parameter, Url.IsLocalUrl(), LocalRedirect(), ControllerBase, PageModel, local URL, Identity UI, OpenID Connect

29.4.2 Avoiding SQL injection attacks with EF Core and parameterization

This section explains how SQL injection arises from concatenating untrusted input into queries and how EF Core LINQ queries and parameterized raw SQL prevent it.

• SQL injection threat: Explain how SQL injection lets an attacker use malicious input from forms, URLs, or query strings to cause unintended database operations or expose database data.
  Why it matters: A single injectable query can give an attacker access to data or allow destructive changes to your database.
• EF Core query safety: Describe why standard EF Core LINQ queries are protected from SQL injection: EF Core generates parameterized SQL rather than treating input as concatenated SQL text.
  Why it matters: Using an ORM in its normal LINQ-based style avoids a major class of database vulnerability automatically.
• Raw SQL parameterization: Apply safe raw-query practice by avoiding string concatenation with user-controlled input and using parameterized queries when calling EF Core's FromSqlRaw() or low-level ADO.NET APIs.
  Why it matters: Raw queries bypass the safety of ordinary LINQ construction unless values are passed as parameters instead of merged into query text.

Key terms: SQL injection, malicious input, SQL statements, Entity Framework Core, EF Core, object-relational mapper, ORM, LINQ, parameterized queries, FromSqlRaw()

29.4.3 Preventing insecure direct object references

This section explains how predictable URL object IDs can expose unauthorized resources and why endpoint-level resource-based authorization is the required defense.

• Insecure direct object references: Describe an insecure direct object reference as a vulnerability in which a user changes an object identifier in a URL to access or edit an entity they are not permitted to access.
  Why it matters: Recognizing this attack helps you protect resources even when an attacker manually changes a URL.
• Endpoint resource authorization: Explain that endpoint handlers must use resource-based authorization to verify that the current user may access the particular entity requested, returning a permission-denied error when they may not.
  Why it matters: Authorization at the endpoint prevents users from bypassing the UI by entering a URL directly.
• UI restrictions versus security: Distinguish hiding or disabling UI elements from actual security: these UI choices can improve user experience but cannot restrict access without resource-based authorization in the endpoint.
  Why it matters: A browser UI is under the user's control, so server-side authorization must enforce the access rule.
• GUIDs as obscurity: Explain that using pseudorandom GUIDs instead of sequential integer IDs makes entities harder to guess but only masks an authorization flaw; GUIDs can still be useful for publicly accessible pages whose IDs should not be easily discoverable.
  Why it matters: Hard-to-guess identifiers can reduce casual enumeration but must never replace authorization.

Key terms: insecure direct object reference, entity, database ID, resource-based authorization, endpoint handlers, permission-denied error, UI, Edit button, GUID, pseudorandom globally unique identifier

29.4.4 Protecting your users’ passwords and data

This section outlines practical minimum practices for minimizing, protecting, and securely handling users’ personal data, passwords, and authentication information.

• Data minimization and identity outsourcing: Explain why an application should collect and store only user data it genuinely needs, and describe how using a third-party identity service can reduce the burden of protecting personal information.
  Why it matters: Data you never collect or store cannot be exposed in a breach.
• Password and sign-in safeguards: Describe the required safeguards for user credentials: never store passwords directly, store only expensive cryptographic hashes such as BCrypt or PBKDF2, support MFA, and reject known weak or compromised passwords.
  Why it matters: Weak credential storage or weak sign-in protections can let attackers take over users’ accounts.
• Cookie and account-disclosure protections: Describe how authentication cookies should be protected with HttpOnly, Secure, and where possible SameSite=Strict settings, and explain why an app should not reveal whether a user is registered.
  Why it matters: Secure cookie settings reduce credential exposure, while hiding registration status helps prevent account enumeration.
• Early security design: Explain why security should be considered while building the application rather than bolted on at the end, and state that ASP.NET Core’s basic protections do not remove the need for secure application design and input validation.
  Why it matters: Building security in early is easier than retrofitting defenses after sensitive data and insecure behavior are already present.

Key terms: data protection laws, PCI compliance, third-party identity service, ASP.NET Core Identity, cryptographic hashes, BCrypt, PBKDF2, multifactor authentication, MFA, weak passwords

29.5 Summary

This summary recaps how to defend an ASP.NET Core application against common web attacks, control cross-origin API access, and protect user data.