Allow Microsoft UET consent endpoint in CSP

[spizeck]

Problem

Production CSP is blocking Microsoft UET's consent-state request to https://bat.bing.net/actionp/....

Observed browser console error:

Connecting to 'https://bat.bing.net/actionp/...&evt=consent&src=default...' violates the following Content Security Policy directive: connect-src ... https://bat.bing.com ...

The current CSP allows https://bat.bing.com but not https://bat.bing.net.

Why this matters

We have already fixed the GTM/Cookiebot side:

• Cookiebot establishes default denied consent before normal tags run.
• UET base tag inherits initial consent from GTM and accepts updates.
• explicit Microsoft UET default-denied command fires at Consent Initialization.
• Clarity is gated on analytics_storage and Meta on ad_storage.
• Clarity Consent API v2 sync mirrors Cookiebot updates correctly.
• UET Insights is disabled.

Production still creates _clck / _clsk before a visitor makes a choice, while Preview behaves correctly.

Network/console evidence shows UET attempting to send its default-denied consent signal to bat.bing.net, but CSP blocks that request. This is the strongest remaining production-only difference.

Goal

Add the minimum CSP allowance needed for Microsoft's UET consent endpoint so the consent-default request is not blocked.

Required change

Allow the exact origin:

https://bat.bing.net

under connect-src.

Do not replace this with a wildcard and do not broadly loosen CSP.

Keep the existing https://bat.bing.com allowance unless investigation proves it should be removed.

Investigation

Before changing code, locate the repo's canonical CSP/security-header configuration and confirm the current Microsoft-related directives.

Verify that bat.bing.net is absent and that this exact absence explains the console violation.

Also check whether any tests/docs enumerate allowed Microsoft origins and need updating.

Validation

Add/update focused regression coverage so future CSP changes preserve the exact required Microsoft origins.

Run the normal repo validation, including at minimum:

• npm run check
• lint
• typecheck
• unit/integration tests
• production build
• security-header/CSP tests
• relevant smoke/e2e coverage

If practical, verify against a production-like build that the generated CSP contains both https://bat.bing.com and https://bat.bing.net and no broader Microsoft wildcard.

Post-deploy verification

After merge/deploy, verify in a fresh production browser context:

1. no CSP error for bat.bing.net/actionp
2. before any Cookiebot choice, Clarity metadata reports denied/denied
3. _clck and _clsk remain absent before consent
4. Reject optional keeps them absent
5. Allow all switches Clarity to granted/granted and expected cookies appear

Do not change GTM/Cookiebot/Clarity configuration in this issue unless the repo investigation finds a direct dependency.

Boundaries

• no blanket CSP wildcard
• no disabling UET, Clarity, Cookiebot, Sentry, or Vercel Analytics
• no unrelated analytics changes
• no Sentry ignore rules
• do not merge

Final report

Report:

1. base SHA
2. branch/head SHA
3. PR number/link
4. exact CSP file/config changed
5. before/after connect-src Microsoft origins
6. tests added/updated
7. full validation results
8. confirmation no wildcard/broadening was introduced
9. post-deploy verification steps
10. whether any additional Microsoft endpoints were discovered and why they were or were not added