feat(http): [Data Collection 13] Apply cookie collection policy

[adinauer]

PR Stack (Data Collection)

• feat(core): Data Collection #5759
• feat(core): [Data Collection 1] Add configuration types #5760
• feat(core): [Data Collection 2] Expose SentryOptions API #5761
• feat(core): [Data Collection 3] Add policy resolver #5799
• feat(graphql): [Data Collection 4] Apply GraphQL policies #5800
• feat(database): [Data Collection 5] Apply query policy #5801
• feat(spring): [Data Collection 6] Apply incoming request body policy #5802
• feat(apollo): [Data Collection 7] Apply incoming response body policy #5803
• feat(apollo): [Data Collection 8] Apply outgoing request body policy #5804
• feat(graphql): [Data Collection 9] Apply outgoing response body policy #5805
• feat(http): [Data Collection 10] Apply request header policy #5806
• feat(http): [Data Collection 11] Apply response header policy #5807
• feat(http): [Data Collection 12] Apply query parameter policy #5810
• feat(http): [Data Collection 13] Apply cookie collection policy #5811
• feat(user): [Data Collection 14] Apply user information policy #5812

---

📜 Description

Apply the cookie Data Collection policy to automatically captured request and response cookies.

The policy is used by Spring MVC/WebFlux, OkHttp, Ktor, and Apollo 3/4 failed-request events. Explicit Data Collection supports off, deny-list, and allow-list behavior. Built-in sensitive cookie names and Spring integration-provided session cookie names are always filtered, including when allow-listed. Set-Cookie values are parsed separately so attributes such as Path, HttpOnly, and SameSite are preserved.

When Data Collection is absent, integrations preserve their existing sendDefaultPii behavior, including Spring's legacy security-cookie filtering and raw HTTP-client cookie values.

💡 Motivation and Context

Cookie collection previously relied on sendDefaultPii as an on/off gate, with filtering only in Spring integrations. This wires the existing dataCollection.cookies option across cookie capture paths and provides consistent explicit-mode filtering without changing the legacy bridge for applications that have not configured Data Collection.

Refs #5666

💚 How did you test it?

• ./gradlew spotlessApply apiDump
• ./gradlew :sentry:apiCheck
• Core cookie filtering tests
• OkHttp and Ktor failed-request tests
• Spring, Spring Jakarta, and Spring 7 request tests
• Apollo 3 and Apollo 4 test suites
• git diff --check

📝 Checklist

• I added GH Issue ID & Linear ID
• I added tests to verify the changes.
• No new PII added or SDK only sends newly added PII if sendDefaultPII is enabled.
• I updated the docs if needed.
• I updated the wizard if needed.
• Review from the native team if needed.
• No breaking change or entry added to the changelog.
• No breaking change for hybrid SDKs or communicated to hybrid SDKs.
• Public API changes reviewed by another Mobile SDK team member or implemented according to the develop docs spec.

🔮 Next steps

Complete the remaining Data Collection configuration, documentation, and migration work.

#skip-changelog

⚠️ Merge this PR using a merge commit (not squash). Only the collection branch is squash-merged into main.

[github-actions]

	Messages
📖	Do not forget to update Sentry-docs with your feature once the pull request gets approved.

Generated by 🚫 dangerJS against 268920f

[sentry]

📲 Install Builds

Android

🔗 App Name	App ID	Version	Configuration
SDK Size	io.sentry.tests.size	8.48.0 (1)	release

⚙️ sentry-android Build Distribution Settings

[github-actions]

Performance metrics 🚀

	Plain	With Sentry	Diff
Startup time	316.30 ms	372.60 ms	56.30 ms
Size	0 B	0 B	0 B

Baseline results on branch: feat/data-collection-query-params

Startup times

Revision	Plain	With Sentry	Diff
475fcd3	319.94 ms	371.16 ms	51.22 ms

App size

Revision	Plain	With Sentry	Diff
475fcd3	0 B	0 B	0 B