Security FAQ on Antiforgery Token Design and Mitigations

Bold Reports implements strong defenses against Cross-Site Request Forgery (CSRF) attacks using antiforgery tokens to validate state-changing requests. In Bold Reports, the antiforgery (CSRF / XSRF) token cookie (such as XSRF-TOKEN, BOLD_UMS_XSRF_TOKEN, or boldreports_antiforgery_token) is intentionally not marked as HttpOnly. This behavior supports secure JavaScript-based communication during application initialization and normal operations.
This article explains why the antiforgery token must be accessible to JavaScript and why this design does not introduce a security vulnerability.

What is Cross-Site Request Forgery (CSRF)?

Cross-Site Request Forgery (CSRF) is an attack that tricks an authenticated user’s browser into sending unintended requests to a trusted application.

Because browsers automatically include cookies with requests, attackers may attempt to perform unauthorized actions such as:

• modifying reports
• exporting data
• triggering report operations

Antiforgery tokens help prevent these unauthorized actions.

Double-Submit Cookie Pattern

Bold Reports uses the standard and widely accepted double-submit cookie pattern for CSRF protection. This approach is optimized for applications that rely heavily on AJAX requests, which are common in reporting workflows such as report loading, parameter submission, and startup initialization.

Why We Use a JavaScript-Accessible Antiforgery Token

Bold Reports uses a standard and widely accepted CSRF defense mechanism called the double-submit cookie pattern, in which the antiforgery token is intentionally made accessible to JavaScript.
If the antiforgery cookie were marked HttpOnly:

• JavaScript would not be able to read the token.
• CSRF validation for AJAX requests would fail.
• Startup initialization, report rendering, and other AJAX-based operations would break.
  For these reasons, the token is intentionally readable by JavaScript to support these functional requirements while still maintaining effective CSRF protection.

How the mechanism works

1. The server generates a secure, unpredictable antiforgery token.
2. The token is stored in a cookie (for example: boldreportsserver_antiforgery_token, XSRF-TOKEN, or .AspNetCore.Antiforgery.* depending on the deployment).
3. JavaScript reads the token value from the cookie.
4. The token is included in AJAX request headers for all non-GET operations.
5. The server validates the token on every relevant request and rejects mismatches.
   This double-submit pattern ensures the request originates from the legitimate application, since attackers cannot forge matching cookie and header values across origins.
   The token is generated and validated exclusively on the server; the client only reads and returns it unchanged.

Why This Does Not Introduce a Security Vulnerability

The antiforgery (XSRF) token cookie is accessible to JavaScript by design. However, this does not introduce a security vulnerability for the following reasons:

1. It Is Not an Authentication or Session Cookie

The XSRF token:

• Does not contain user credentials
• Does not represent a login session
• Cannot authenticate a user
• Cannot be used to hijack a session
  Even if the token is accessible to JavaScript, it does not grant access to protected resources. All authentication and session cookies remain protected using the HttpOnly flag.

2. The Token Is Fully Controlled by the Server

The antiforgery token is:

• Securely generated by the server
• Stored and validated server-side
• Verified on every request

The client cannot generate, modify, or alter the token. It only reads the value and returns it in request headers for validation. Any alteration results in immediate rejection. This ensures that token integrity is always enforced by the server.

3. HttpOnly Cannot Be Enabled Due to Functional Requirement

The HttpOnly flag prevents JavaScript from reading cookies. In this implementation:

• JavaScript must read the antiforgery token.
• The token must be included in AJAX request headers.
• Startup, provisioning, and normal API operations depend on this behavior.

If HttpOnly were enabled for this cookie:

• JavaScript would not be able to read the token.
• CSRF validation would fail.
• Core application workflows would break.

Therefore, HttpOnly is intentionally not enabled for this specific cookie only.

4. XSS Protections Are Already in Place

The primary risk scenario requires a successful Cross-Site Scripting (XSS) attack to extract the token. However, Bold Reports mitigates this through:

• Input fields sanitization.
• Prevention of common XSS payload execution.
• Avoidance of reflecting executable scripts from the server.
• Support for Content Security Policy (CSP) headers to restrict resource loading and script execution.
  Without a successful XSS attack, the token cannot be extracted or misused.

Conclusion

The antiforgery token being accessible to JavaScript is a controlled and necessary implementation for secure CSRF protection in AJAX-based workflows. It does not expose credentials, does not allow authentication bypass, and is protected by multiple security layers. Therefore, this behavior does not introduce a security vulnerability.