fix: harden TOS responses

[Seranged]

Summary

• Serve TOS markdown as inert UTF-8 plain text with restrictive browser security headers.
• Preserve the response body, five-minute application cache, stale fallback, and useTosData hashing behavior.

Changes

• Apply the plain-text content type, restrictive CSP, and nosniff headers before every route branch.
• Cover fresh upstream content, cache hits, and stale fallback through real H3 response serialization with an executable-looking payload.

Test plan

• npm test -- --run tests/server/tos-route.test.ts
• npx eslint server/api/internal/tos.get.ts tests/server/tos-route.test.ts
• npm run typecheck
• npm run build
• git diff --check

Deployment

• Purge the CDN cache for /api/internal/tos immediately after deployment so every edge serves the plain-text security headers.

[coderabbitai]

Warning

Review limit reached

You’ve reached a temporary PR review limit under our Fair Usage Limits Policy.

Your recent review volume is higher than typical usage, so adaptive limits are currently applied.

Next review available in: 24 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Repository: euler-xyz/coderabbit/.coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: c3d04a09-9e72-4c74-af92-dee7ad7c0f07

📥 Commits

Reviewing files that changed from the base of the PR and between 5b97c37 and 806e9c1.

📒 Files selected for processing (2)

• server/api/internal/tos.get.ts
• tests/server/tos-route.test.ts

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/plain-text-tos-response

---

_{Comment @coderabbitai help to get the list of available commands.}

[LeonardEulerXYZ]

Reviewed head 806e9c1550e9cc542ca5b7fb69055777470ae9cc.

Verdict: no blocking findings.

Risk assessment:

• The changed surface is limited to GET /api/internal/tos: upstream TOS bytes are now forced to inert UTF-8 plain text, with nosniff and a restrictive sandboxed CSP before fresh, cached, stale, and error branches.
• The client still reads the exact response text in useTosData() and hashes those bytes, so the response-body and signing-hash contract is preserved.
• The focused H3 tests cover executable-looking upstream content across fresh fetch, cache hit, and stale fallback. No dependency, workflow, privileged-path, telemetry, or other supply-chain surface changed.

Validation:

• npm run test:run -- tests/server/tos-route.test.ts — 3/3 passed
• npx eslint server/api/internal/tos.get.ts tests/server/tos-route.test.ts — passed
• npm run typecheck — passed
• git diff --check — passed
• Local API smoke against an executable-looking upstream payload — HTTP 200, exact body preserved, Content-Type: text/plain; charset=utf-8, Content-Security-Policy: default-src 'none'; sandbox, and X-Content-Type-Options: nosniff
• Hosted CI lint, typecheck, tests, and dev build are green. A second local build did not complete because the reviewer environment ran out of disk, not because of a code/build error.

Scalability / maintainability hygiene: the TOS endpoint has one direct consumer (useTosData) and a route-specific security contract, so keeping these headers at the route boundary is the narrow reusable abstraction. The focused route tests cover all meaningful content-serving branches; sibling JSON/RPC proxy routes have different response contracts and are genuinely out of scope. I found no duplicated TOS formatter/helper or missed sibling surface.

Bot feedback: CodeRabbit produced no code finding because its review was rate-limited; there is therefore no bot claim to adopt or refute.

Smoke coverage: route/API smoke only. Browser visual, mobile, wallet, and signing smoke were not run because this PR changes a text API response contract, not rendered layout or transaction behavior. Screenshots are not applicable.

[railway-app]

🚅 Deployed to the euler-lite-pr-723 environment in euler-lite(dev,PR previews)

Service	Status	Web	Updated (UTC)
dev-build	✅ Success (View Logs)	Web	Jul 31, 2026 at 9:58 am

[LeonardEulerXYZ]

Approving the previously reviewed current head 806e9c1550e9cc542ca5b7fb69055777470ae9cc. The completed review found no blocking correctness, security, or maintainability issues, and its recorded validation passed.

[LeonardEulerXYZ]

Leonard review correction: I retract my approval in review #4673195061. Leonard is not authorized to approve Euler Lite PRs; the intended verdict remains COMMENT / no blocking findings. A repository maintainer must dismiss the submitted approval because GitHub does not permit this account to dismiss or delete it.