Security Architecture Report: One-Time Demo-Login Link Implementation in ASP.NET Core MVC

Full report

On this page

Executive Verdict

The introduction of a secret-bearing URL for authentication fundamentally alters the threat model of the ASP.NET Core MVC application by shifting the authentication factor from an interactive credential exchange to the possession of a bearer token transmitted via the Uniform Resource Identifier (URI). While the system operates in a pre-public, non-live state, the architectural decisions codified during this phase will persist as critical technical security debt if implemented incorrectly. The preliminary planned behavior contains severe structural vulnerabilities, most notably the intention to consume the authentication token directly via an HTTP GET request and the implicit risk of session fixation if the application merely mutates the existing session dictionary without cryptographic rotation. The canonical design mandates the strict abandonment of direct GET-based token consumption. The modern internet ecosystem—characterized by aggressive enterprise email security gateways, anti-virus detonation chambers, link-unfurling bots, and browser speculative prefetching—renders GET consumption highly fragile and inherently insecure1. Instead, the system must utilize an interstitial confirmation pattern where the initial GET request passively renders a secure form, and an anti-forgery-protected POST request atomically consumes the token to establish the session. Furthermore, the application must enforce strict identity rotation upon authentication; merely swapping the normalized username within an existing session constitutes a critical Session Fixation vulnerability (CWE-384)3. The legacy session identifier must be cryptographically destroyed, the server-side session dictionary explicitly cleared, and a new high-entropy session identifier generated. Implementing the recommendations detailed in this report will align the architecture with the OWASP Application Security Verification Standard (ASVS) v4.0.3 requirements for session management and authentication5.

Assets and Trust Boundaries

The system architecture introduces new physical and logical entities to the authentication flow, necessitating a rigorous re-evaluation of trust boundaries. Defining these boundaries is critical to preventing privilege escalation and data leakage across the application infrastructure.

The primary trust boundary is crossed when the token leaves the generation console and enters the communication channel destined for the user. Once the URL is constructed, the token is exposed to the operating system's clipboard, enterprise email inspection tools, and network transit layers. The ASP.NET Core MVC application must operate under the assumption that the token has traversed hostile environments and must validate all assertions before elevating privileges across the server-side trust boundary.

Threat Model

The transition to a URI-based authentication mechanism introduces a complex matrix of attack vectors. The following threat model evaluates the proposed implementation against established adversarial techniques, addressing the specific risks of token leakage, state manipulation, and concurrent exploitation.

Token Leakage Vectors

When a secret token is embedded directly into a URL, it violates the principle of keeping sensitive credentials out of URI paths. This architectural choice exposes the token to numerous uncontrolled logging and observation mechanisms. The browser history natively records the full URL of every visited page; thus, the plaintext token will be persisted to the local disk of the user's machine and potentially synchronized across their devices via cloud-based browser profiles. If the user subsequently navigates from the redemption endpoint to an external site (or if the application loads third-party resources such as Content Delivery Network (CDN) scripts, custom fonts, or analytics pixels), the browser will transmit the full URL in the Referer header, leaking the credential to external third parties7. Within the infrastructure layer, reverse proxies, web application firewalls (WAFs), and the primary web server (IIS or Kestrel) natively record the complete Request-URI in their access logs8. A token passed as a GET query parameter will be persisted in cleartext across the logging infrastructure, violating OWASP logging guidelines which mandate the sanitation of authentication secrets9. Furthermore, application-level telemetry and exception tracking systems (e.g., Application Insights) often capture the request context. If a framework-level exception occurs during redemption—such as a database timeout—the raw token may be embedded in the exception message or recorded in error logs. At the human layer, users frequently copy URLs to their clipboard for later use, exposing the token to other installed applications, or share screenshots with IT support personnel, inadvertently archiving the live credential in support ticketing systems.

State Manipulation and Authentication Vulnerabilities

The authentication flow is susceptible to several sophisticated state manipulation attacks if the framework is not strictly configured.

Direct-GET versus Confirmation-POST Decision

The original planned behavior outlines direct token consumption via an HTTP GET request, mapped to the endpoint /demo-login?token=\<canonical-base64url-token\>. This design pattern fundamentally violates RFC 9110 HTTP semantics, which dictate that GET requests must be safe and idempotent, meaning they should not trigger side effects or alter the persistent state of the server15. Consuming a single-use cryptographic token irreparably alters server state by invalidating the token and establishing a new authenticated session. Beyond semantic purity, implementing state-changing operations via GET exposes the application to catastrophic operational failures due to the automated nature of the modern web. Modern web browsers, including Google Chrome and Microsoft Edge, heavily utilize speculative execution and prefetching. When a user hovers over a link, or when a link is parsed within the Document Object Model (DOM), the browser may silently issue a background GET request to resolve the DNS, negotiate the TLS handshake, and fetch the payload to decrease perceived latency. This background request will consume the token immediately. When the user subsequently clicks the link explicitly, the token will be evaluated as expired or already used, resulting in a locked-out user. Furthermore, the enterprise ecosystem is heavily guarded by automated security scanners. Systems such as Microsoft Defender for Office 365, Proofpoint, and Mimecast dynamically rewrite inbound email URLs and detonate them in sandbox environments to analyze their behavior and detect phishing payloads1. These scanners programmatically issue HTTP GET requests. Consequently, the enterprise gateway will successfully authenticate and consume the token before the email ever reaches the user's inbox. Chat applications, such as Slack, Microsoft Teams, and Apple iMessage, exhibit similar behavior; pasting a link into a chat window triggers a link-unfurling bot that issues a GET request to scrape Open Graph metadata, instantly burning the single-use token.

The Interstitial POST Confirmation Architecture

The canonical, materially safer approach separates the transit of the token from the consumption of the token. The application must implement an interstitial confirmation pattern. The initial GET request to /demo-login?token=... remains completely passive. It evaluates the syntactic validity of the token (e.g., verifying it is a valid base64url string of the correct length) but does not query the database to consume it. Instead, the endpoint renders a lightweight HTML interstitial page containing a CSRF-protected form and a single call-to-action button, such as "Continue to Application." When the user clicks the button, the browser initiates an HTTP POST request. This POST request carries the framework's anti-forgery token alongside the secret authentication token. The server then performs the atomic consumption and session establishment. This architecture entirely circumvents the hazards of prefetching, email detonation, and chat unfurling, because automated security scanners and link-preview bots do not execute state-changing POST requests15. This design fully satisfies the product requirement for "a link that logs the demo user in." The user experience involves clicking the link in their email, landing on a branded application page, and clicking a single button to proceed. This minimal friction is universally accepted in enterprise environments and is vastly superior to the high failure rates associated with direct GET consumption.

Residual Risks of Mandatory GET Consumption

If organizational constraints dictate that direct GET consumption remains an unalterable product requirement, the system must accept a permanently degraded user experience and a high volume of support inquiries due to inadvertently burned tokens. The safest possible sequence for a mandatory GET implementation involves issuing the token with an extremely short time-to-live (e.g., 5 to 15 minutes) to limit the exposure window14. The application would have to explicitly bypass anti-forgery (CSRF) protections for the authentication endpoint, as GET requests cannot natively carry standard anti-forgery form tokens. The residual risk is that a significant, unpredictable percentage of users will click the link and immediately receive an "Invalid Token" error due to their local anti-virus or corporate firewall having pre-fetched the URI moments prior1. Due to these severe detriments, the interstitial POST confirmation sequence is the only professionally recommended path.

Recommended Canonical Request/Response Sequence

To securely implement the interstitial POST confirmation pattern, the following logical sequence must be rigorously enforced within the ASP.NET Core MVC routing and middleware pipeline.

Phase 1: The Initial GET Request (Passive Rendering)

The user navigates to the application via the provided link: GET /demo-login?token=\<canonical-base64url-token\>. The ASP.NET Core framework extracts the query parameter. The controller validates the format of the token using a regular expression to ensure it conforms to the expected base64url alphabet and length, preventing basic injection attacks. Crucially, the controller must invoke HttpContext.Session.Clear() to purge any pre-existing application session data bound to the current HTTP context. This ensures that if an existing user clicks the link, their previous session state is eradicated, preventing state contamination or existing-user replacement. The endpoint returns an HTML view. To prevent Referer header leakage, this specific view must be devoid of external assets; all CSS must be inlined, and third-party scripts (including analytics) must be strictly excluded. The view presents a secure \<form method="POST" action="/demo-login"\>. The form incorporates an ASP.NET Core Anti-Forgery token generated via @Html.AntiForgeryToken() or the built-in TagHelper, and a hidden input field containing the demo token15.

Phase 2: The POST Redemption (Active Consumption)

The user clicks the confirmation button, transmitting POST /demo-login. The ASP.NET Core pipeline intercepts the request and evaluates the Anti-Forgery token using the \[ValidateAntiForgeryToken\] attribute15. If the token is missing or invalid, the request is immediately rejected, mitigating Login CSRF attacks. The server explicitly commands the browser to delete the existing session cookie by invoking Response.Cookies.Delete, destroying the pre-authentication session identifier. The application then calculates the SHA-256 hash of the submitted token. To consume the token atomically and prevent race conditions, the application executes a single database operation. In SQL Server, this must be an UPDATE statement utilizing the OUTPUT clause, or a transaction enforcing an exclusive update lock (UPDLOCK, HOLDLOCK):

SQL UPDATE DemoTokens SET UsedAt \= SYSUTCDATETIME() OUTPUT inserted.Username, inserted.Role WHERE TokenHash \= @CalculatedHash AND UsedAt IS NULL AND ExpiresAt \> SYSUTCDATETIME();

This query pattern explicitly prevents concurrent redemption vulnerabilities. If two parallel requests hit the database simultaneously, the database engine's locking mechanisms ensure that only the first transaction evaluates UsedAt IS NULL as true5. The second transaction will evaluate the condition as false and return zero rows. Following successful consumption, the server evaluates the returned data to verify that the username is active and explicitly verifies that the account does not possess administrative privileges11. If this authorization boundary check fails, the authentication is aborted. The application then instantiates a new session dictionary and issues a completely new, cryptographically secure session cookie bound to the normalized username kappel-kappel. The server concludes this phase by issuing an HTTP 303 See Other redirect.

Phase 3: The Token-Free Redirect

The application must defend against Open Redirect vulnerabilities during the post-authentication phase. The server responds with a 303 See Other status code. Upon a successful redemption, the application issues a Location: /counties header. This destination route must be hardcoded or validated against a strict safelist of internal paths. The URL contains no sensitive parameters, query strings, or fragments. If the redemption fails due to an invalid, expired, or unauthorized token, the application issues a Location: /demo-login/error header.

Identity Rotation and Session Fixation

The treatment of the session identifier is the most critical technical control in this architecture. The original prompt suggests that the session stores the normalized username. A common, yet catastrophic, developer error is to merely update the username value within the existing HttpContext.Session dictionary: HttpContext.Session.SetString("username", "kappel-kappel"). This approach is fundamentally flawed because the underlying session cookie (e.g., .AspNetCore.Session) remains constant. The HttpContext.Session is merely a server-side cache mapped to the client-side cookie17. If an attacker can force a victim to navigate to the application with a pre-set session cookie (a technique easily achievable via cross-site scripting on a neighboring subdomain or via HTTP response splitting), and the victim subsequently authenticates via the demo link, the application will elevate the privileges of the existing cookie. The attacker, possessing that identical cookie, will instantly gain full access to the kappel-kappel account. This constitutes a severe Session Fixation vulnerability (CWE-384)3. To adequately rotate identity and comply with OWASP ASVS requirement 3.2.1, the old session identifier must be cryptographically destroyed, and the session contents eradicated5. The application must invoke HttpContext.Session.Clear() to wipe the server-side dictionary. Furthermore, it must instruct the client to discard the legacy cookie and issue a new cookie with a high-entropy identifier (at least 64 bits of entropy)4. In ASP.NET Core, regenerating the session ID often requires clearing the cookie and allowing the middleware to generate a fresh identifier on the subsequent request, or utilizing the authentication middleware's native SignInAsync methods which handle principal rotation securely.

Required Headers and Cookie/Session Settings

To secure the session state and prevent client-side data leakage, the ASP.NET Core SessionOptions and CookieBuilder must be configured with maximal strictness within the application's configuration pipeline (e.g., Program.cs).

Both the redemption responses (the interstitial GET and the POST action) and the failure responses must emit strict HTTP security headers to govern browser behavior.

1. Cache-Control and Pragma: The application must emit Cache-Control: no-store, no-cache, max-age=0, must-revalidate, alongside Pragma: no-cache and Expires: 0\. This configuration explicitly forbids browsers and intermediary proxies from storing the HTML containing the token or the authenticated session data on physical disk. If a user authenticates, logs out, and subsequently clicks the browser's "Back" button, the no-store directive forces the browser to request the page from the server, which will deny access because the session was terminated8.

2. Referrer-Policy: The application must enforce Referrer-Policy: no-referrer. This completely prevents the browser from sending the current URL—which contains the sensitive token during the GET request—in the Referer header when fetching external assets or navigating to another page, halting a primary token leakage vector8.

3. Content-Security-Policy (CSP) and Frame Protections: The application must emit Content-Security-Policy: default-src 'self'; frame-ancestors 'none'; form-action 'self'; and X-Frame-Options: DENY. The frame-ancestors 'none' directive prevents the application from being embedded in a malicious iframe, neutralizing Clickjacking and UI redressing attacks24. The form-action 'self' directive ensures the critical POST request can only be submitted back to the application itself, preventing token exfiltration via form hijacking.

4. X-Content-Type-Options: The header X-Content-Type-Options: nosniff must be present to prevent MIME-sniffing vulnerabilities, ensuring the browser strictly adheres to the declared content types.

Safe Failure UX and Uniform Wording

The application must never operate as an oracle that allows an attacker to deduce the underlying state of a token or the existence of specific accounts. Providing distinct, granular error messages—such as distinguishing between a "Token already used" message and a "Token expired" message—allows an attacker to continuously probe hashes to map user activity, deduce the lifespan of tokens, or brute-force valid states11. Regardless of whether a token is invalid, malformed, expired, replayed, invalidated, or unauthorized (e.g., cryptographically valid but improperly tied to an admin account), the application must return a single, uniform HTTP 200 OK view (rendered after the 303 redirect) or a standard 400 Bad Request page featuring the exact text: "This login link is invalid, expired, or has already been used. Please contact support or request a new link."

This uniform wording is highly informative to the legitimate user—who immediately understands the remediation step requires requesting a new link—while yielding absolutely zero cryptographic, temporal, or state information to an adversary.

Logout Behavior, Tab Management, and Replay

When a user initiates a logout sequence, the server must explicitly invalidate the session to prevent post-termination exploitation. In ASP.NET Core, this requires invoking HttpContext.Session.Clear() to wipe the server memory and simultaneously destroying the client-side cookie using Response.Cookies.Delete("\_\_Host-AppSession"). If the application utilizes a database-backed session store (such as a distributed Redis cache or SQL Server), the session identifier must be explicitly marked as destroyed in the backend store to prevent token replay17. Because all authenticated pages and the interstitial login page enforce strict Cache-Control: no-store directives, clicking the browser's Back button after logout will not render a cached version of the sensitive application state. Instead, it will result in a hard network request to the server. The server, recognizing the absence of a valid session cookie, will issue a redirect routing the user to the login page25. Session management relies on the browser's shared cookie jar, which spans across multiple tabs. If a user opens the application in two tabs, logs out in Tab A, and then attempts to interact with the application in Tab B, the request from Tab B will be transmitted without a valid session cookie. The server will intercept this unauthenticated request and seamlessly redirect Tab B to the login page, ensuring state consistency across the client environment. If a user logs out and then attempts to click the original demo-login link a second time, the request will fail safely. The token was atomically consumed during the initial POST request, transitioning the database UsedAt column from NULL to a timestamp. The subsequent database query will return zero valid records, and the uniform safe failure UX will be displayed, neutralizing token replay attacks.

Protection Against Administrators and Inactive Users

The separation of duties between the console application generating the token and the web application redeeming it necessitates robust authorization checks at the point of consumption. The application must not implicitly trust that the token generator correctly mapped the token to the demo account. During Phase 2 (The POST Redemption), after the database returns the Username and Role associated with the token hash, the application must execute a strict authorization boundary check. The server must evaluate the target account to ensure it is marked as active within the identity provider. Crucially, the server must explicitly evaluate the Role claims and reject the authentication attempt if the account possesses any administrative privileges, even if the cryptographic token is perfectly valid11. If this check fails, the application must immediately abort the session establishment process, log a high-severity security event internally, and display the standard uniform failure UX to the user.

Production Configuration Gates (Failing Closed)

To prevent misconfigurations in deployment pipelines from silently degrading the application's security posture, the startup sequence (e.g., Program.cs) must incorporate configuration gates that throw fatal exceptions, causing the process to fail closed if unsafe conditions are detected:

1. HTTPS Enforcement Gate: The application must verify that it is not exposed over non-loopback HTTP. The application must explicitly register app.UseHttpsRedirection() and app.UseHsts() in the middleware pipeline. If the environment is marked as production, a startup check should assert that these middlewares are active.

2. Cookie Policy Gate: If the runtime environment or an overriding configuration file attempts to downgrade the SameSite policy to None or the Secure policy to None, the application should throw an InvalidOperationException and halt execution.

3. Data Protection Persistence: ASP.NET Core relies heavily on the Data Protection API to encrypt the session cookie payload and manage cryptographic key rings17. If the Data Protection key ring is not explicitly configured for a persistent store (e.g., if it falls back to ephemeral in-memory keys), the application should fail to start in production. Ephemeral keys cause application restarts to immediately invalidate all active sessions, leading to unpredictable behavior and potential security bypasses if default keys are utilized.

Logging and Observability Rules

Security observability is essential for incident response, anomaly detection, and auditing. However, logging raw secrets creates catastrophic secondary breach vectors. The application access logs, web application firewalls, and application-level telemetry must strictly adhere to the following data sanitation rules.

Abuse Controls

While the token generator operates as an isolated, local console application, the redemption endpoint (/demo-login) is publicly exposed and highly susceptible to brute-force attacks. An adversary could deploy automated tooling to rapidly submit random base64url strings, hoping to collide with a valid, active token hash residing in the database. Because the token is cryptographically random and possesses high entropy (e.g., 128+ bits), the probability of a successful collision is mathematically negligible. However, rapid, continuous SHA-256 hashing consumes significant server CPU cycles, potentially leading to an asymmetric Denial of Service (DoS) attack, and pollutes the security telemetry logs. To mitigate this, the application must implement robust, application-level rate limiting. Utilizing the ASP.NET Core 7.0+ Rate Limiting middleware, the system should apply a fixed window limit to the /demo-login POST endpoint based on the client IP address (e.g., a maximum of 5 to 10 requests per minute). If the limit is exceeded, the server must immediately return a 429 Too Many Requests response, aborting the cryptographic hashing sequence. This control adds minimal complexity to the core domain logic while effectively neutralizing automated probing and resource exhaustion attacks12.

Severity-Ranked Findings

If the development team strictly implements the initial "Planned Behavior" without incorporating the architectural modifications detailed in this report, the application will exhibit the following severe vulnerabilities:

1. Critical (CVSS 9.0+): Session Fixation (CWE-384). The intention to merely update the normalized username within the existing session state, without destroying the underlying .AspNetCore.Session cookie, allows complete account takeover. An attacker can seed a known session identifier, trick the victim into authenticating, and subsequently hijack the fully authenticated kappel-kappel session3.

2. High (CVSS 7.5+): Denial of Service via Scanner Detonation. Implementing token consumption directly via an HTTP GET request will result in near-100% token failure rates for users operating behind corporate email security gateways (e.g., Microsoft Defender, Proofpoint). The gateway will programmatically consume the token, locking out the legitimate human user and rendering the feature functionally broken1.

3. High (CVSS 7.5+): Token Leakage via Infrastructure Logs. Processing the sensitive token as a URL query parameter ensures the plaintext secret is permanently and broadly written to IIS/Kestrel logs, proxy logs, SIEM platforms, and browser histories, creating a massive credential exposure surface8.

4. Medium (CVSS 5.0+): Information Disclosure via Error Oracles. Providing differing error messages for "expired" versus "invalid" tokens allows attackers to map the temporal usage of the application and deduce the lifespan of tokens, facilitating targeted attacks11.

5. Medium (CVSS 5.0+): Race Conditions. Failure to implement strict atomic locking on the database UPDATE statement allows concurrent HTTP requests to redeem the same single-use token multiple times, violating the fundamental security constraint of the feature5.

Security Acceptance Checklist

The following technical controls are prioritized for implementation. The system must not be promoted to a production environment until all "Required" controls are definitively verified.

Adversarial Test Cases

To validate the integrity of the architecture, the Quality Assurance and Security teams must execute the following adversarial test cases prior to deployment:

Residual Risks

Even with the rigorous implementation of the canonical POST-confirmation architecture, certain residual risks must be explicitly accepted by the business, as they cannot be fully mitigated by technical controls:

• Bearer Credential Interception: The token is fundamentally a bearer credential. If a user forwards the email containing the link to an unauthorized third party, or if the link is intercepted via a compromised email account, the system cannot distinguish the attacker from the legitimate user.
• Link Expiration Frustration: To minimize the window of compromise, tokens must be short-lived. Users who request a link but delay clicking it will experience expirations, resulting in increased friction, repeated requests, and potential support inquiries.
• Transient Log Leakage (GET Request): While the POST confirmation stops scanners from burning the token, the initial user click still transmits the token in the GET URL. Consequently, the plaintext token will still reside in the user's local browser history and transient edge infrastructure logs. Because the token is rapidly consumed and single-use, the risk of retrospective exploitation from these logs is negated, but the secret itself remains temporarily visible in local telemetry.
• Shoulder Surfing and Clipboard Exposure: When the user interacts with the link, the token may be exposed visually on the screen (shoulder surfing) or temporarily stored in the operating system's clipboard history, presenting a localized risk of credential theft.

Works cited

1. Step-by-step threat protection stack in Microsoft Defender for Office 365 \- Microsoft Learn, https://learn.microsoft.com/en-us/defender-office-365/protection-stack-microsoft-defender-for-office365

2. Email Protection with Microsoft Defender for Office 365 \- Inovasys, https://www.inovasys.com/en/blogs/email-protection-with-microsoft-defender-for-office-365/

3. What Is Session Fixation? How Attackers Hijack User Sessions \- SentinelOne, https://www.sentinelone.com/cybersecurity-101/cybersecurity/session-fixation/

4. Session Management \- OWASP Cheat Sheet Series, https://cheatsheetseries.owasp.org/cheatsheets/Session\_Management\_Cheat\_Sheet.html

5. OWASP Application Security Verification Standard Report, https://help.hcl-software.com/appscan/Enterprise/10.8.1/topics/r\_owasp\_application\_security\_verification\_standard\_report.html

6. Application Security Verification Standard 4.0 \- BCIT, https://www.bcit.ca/files/its/pdf/owasp-application-security-verification-standard.pdf

7. What is Session Hijacking | Types, Detection & Prevention \- Imperva, https://www.imperva.com/learn/application-security/session-hijacking/

8. Session ID in URL \- Web Application Vulnerabilities \- Invicti, https://www.invicti.com/web-application-vulnerabilities/session-id-in-url

9. Logging \- OWASP Cheat Sheet Series, https://cheatsheetseries.owasp.org/cheatsheets/Logging\_Cheat\_Sheet.html

10. What Is Broken Authentication? Causes, Impact & Prevention \- SentinelOne, https://www.sentinelone.com/cybersecurity-101/identity-security/what-is-broken-authentication/

11. Authorization \- OWASP Cheat Sheet Series, https://cheatsheetseries.owasp.org/cheatsheets/Authorization\_Cheat\_Sheet.html

12. Authentication \- OWASP Cheat Sheet Series, https://cheatsheetseries.owasp.org/cheatsheets/Authentication\_Cheat\_Sheet.html

13. Are Magic Links Secure: A Technical Deep Dive Into Email Based Authentication \- MojoAuth, https://mojoauth.com/blog/are-magic-links-secure-technical-deep-dive

14. CheatSheetSeries/cheatsheets/Multifactor\_Authentication\_Cheat\_Sheet.md at master \- GitHub, https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Multifactor\_Authentication\_Cheat\_Sheet.md

15. Prevent Cross-Site Request Forgery (XSRF/CSRF) attacks in ASP.NET Core, https://learn.microsoft.com/en-us/aspnet/core/security/anti-request-forgery?view=aspnetcore-10.0

16. How to Secure Web App Auth: A Comprehensive Guide \- Clerk, https://clerk.com/articles/authentication-security-in-web-applications

17. Session and state management in ASP.NET Core \- Microsoft Learn, https://learn.microsoft.com/en-us/aspnet/core/fundamentals/app-state?view=aspnetcore-10.0

18. Broken Authentication | Offensive360, https://offensive360.com/knowledge-base/broken-authentication/

19. OWASP ASVS 4.0 Password Security Guidelines | PDF \- Scribd, https://www.scribd.com/document/585110444/OWASP-Application-Security-Verification-Standard-4-0-v3-7-Fill

20. AppSec Cheat Sheet: Session Management \- TrustedSec, https://trustedsec.com/blog/appsec-cheat-sheet-session-management

21. ASP.NET Core 2.1 MVC SameSite cookie sample | Microsoft Learn, https://learn.microsoft.com/en-us/aspnet/core/security/samesite/mvc21?view=aspnetcore-2.2

22. Laravel \- OWASP Cheat Sheet Series, https://cheatsheetseries.owasp.org/cheatsheets/Laravel\_Cheat\_Sheet.html

23. Standard : OWASP Cheat Sheets : Session Management Cheat Sheet \- OpenCRE, https://opencre.org/node/standard/OWASP%20Cheat%20Sheets/section/Session%20Management%20Cheat%20Sheet

24. Content Security Policy · OWASP Cheat Sheet Series, https://owasp.deteact.com/cheat/cheatsheets/Content\_Security\_Policy\_Cheat\_Sheet.html

25. Session Management \- NIST Pages, https://pages.nist.gov/800-63-4/sp800-63b/session/

26. Testing Session Timeout \- WSTG \- Latest | OWASP Foundation, https://owasp.org/www-project-web-security-testing-guide/latest/4-Web\_Application\_Security\_Testing/06-Session\_Management\_Testing/07-Testing\_Session\_Timeout

27. Limit the lifetime of protected payloads in ASP.NET Core \- Microsoft Learn, https://learn.microsoft.com/en-us/aspnet/core/security/data-protection/consumer-apis/limited-lifetime-payloads?view=aspnetcore-10.0

28. OWASP Session Management "Cheat Sheet" \- SANS ISC, https://isc.sans.edu/diary/11263