Actionable comments posted: 5

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@docs/2.utils/2.response.md`:
- Around line 67-70: Correct the encoded-backslash security documentation
consistently at docs/2.utils/2.response.md lines 67-70, src/utils/static.ts
lines 20-34, and src/utils/static.ts lines 73-88: explain that single-encoded
%5c is decoded and normalized before getMeta/getContents lookup, while
double-encoded %255c may survive as literal %5c. Retain the warning that
callback backends must not decode the ID, and preserve the case-folding and
symlink-containment guidance where applicable.

In `@src/utils/cors.ts`:
- Around line 26-29: Update the documentation example near the regex-origin
guidance to match its stated behavior: either change “subdomains” to “an
optional subdomain” for the existing single-label pattern, or revise the pattern
to repeat the escaped subdomain label when arbitrary nested subdomains are
intended.

In `@src/utils/proxy.ts`:
- Around line 256-263: Update proxy() in src/utils/proxy.ts#L256-L263 to
implement the documented filterHeaders support, ensuring configured headers such
as Cookie and Authorization are removed before forwarding opts.headers to the
target. Regenerate docs/2.utils/5.proxy.md#L39-L40 from the corrected source
JSDoc so the documentation accurately describes the working credential-filtering
contract.

In `@src/utils/request.ts`:
- Around line 472-478: The JSDoc currently overstates the safety of URL
components. In src/utils/request.ts lines 472-478, revise the wording to state
that pathname and search are not derived from the spoofable host while still
treating them as untrusted input requiring validation or encoding for their
destination sink; update docs/2.utils/1.request.md lines 256-257, or regenerate
it, to match the qualified wording.

In `@test/unit/cors.test.ts`:
- Around line 238-241: Add negative test cases for https://example.com.evil.test
and https://notexample.com in both isCorsOriginAllowed and createOriginHeaders
coverage, asserting each origin is rejected and does not produce allowed CORS
headers. Keep the existing anchored regex configuration and positive cases
unchanged.

REQUEST CHANGES — one technical inaccuracy in the proxy() credential note; everything else is accurate and well done.

Independent review (I did not author this). Verified against the source on the branch:

Accurate claims (verified in code):

• CORS unanchored: isCorsOriginAllowed uses _origin.test(origin) (unanchored) — note is correct. New anchored test regexes (/^https:\/\/([a-z0-9-]+\.)?example\.com$/, /^https?:\/\/example\.com$/) are valid inputs and the suite passes.
• static %2f/%5c: serveStatic runs resolveDotSegments then decodeURI, which preserves reserved %2f; traversal safety does depend on getMeta/getContents not decoding — accurate.
• redirect/redirectBack: redirectBack enforces refererURL.origin === event.url.origin — the "same-origin referers" wording is correct.
• Host-header trust and getRequestURL/getRequestHost notes are accurate.
• fetchWithEvent "never forwards the event headers to an external URL": correct — the external branch calls fetch(url, init) with no event headers.

No behavioral code changes anywhere in the diff. pnpm vitest run test/unit/cors.test.ts test/proxy.test.ts test/static.test.ts and pnpm lint pass. (The npx automd drift in docs/2.utils/{4.security,5.proxy,9.more}.md is pre-existing on main — emphasis-style/code-wrap only — not introduced here.)

Requested change — proxy() credential note is inaccurate:
The proxyRequest note is correct: it calls getProxyRequestHeaders(event, { filterHeaders }), so filterHeaders: ["cookie","authorization"] does strip them.

But the note added to the lower-level proxy() (src/utils/proxy.ts ~L257-263, mirrored in docs/2.utils/5.proxy.md) recommends the same filterHeaders: ["cookie","authorization"] — and proxy() never reads opts.filterHeaders (grep confirms it is only consumed in getProxyRequestHeaders, i.e. by proxyRequest/fetchWithEvent). proxy() forwards only headers the caller explicitly passes via opts.headers/opts.fetchOptions.headers; it does not auto-forward the incoming request's Cookie/Authorization at all. So on proxy() the recommended mitigation is a silent no-op — worse than no advice in a security note.

Suggested fix: on the proxy() docstring, either point readers to proxyRequest for filterHeaders-based stripping, or state that proxy() forwards only caller-supplied opts.headers verbatim and credentials are controlled by not passing them (filterHeaders has no effect here). Then regenerate docs/2.utils/5.proxy.md.

🤖 Generated with Claude Code