fix(security): restack inherited outbound body guard on protected main - #303
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
📝 WalkthroughWalkthrough
Changes아웃바운드 요청 본문 상속
Estimated code review effort: 2 (Simple) | ~10분 Merge Risk: ⚪ Minimal · up to This localized change tightens inherited outbound-body blocking and adds focused regressions without broadening allowlists; no actionable merge-blocking risk remains at the current head beyond normal checks and review. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Purpose
Restack only the reviewed credential-egress inherited-request-body correction from #299 onto the current protected-main lineage after #298 advanced
main. The predecessor branch remains untouched.Exact construction identity
mainimmediately before construction:10f7874f309cb120bc57b8c0cb637d1292650fe0;6a8ddf172b4bbf0b7d620a4b9269ee9fe24f792e;9926d155f3a02ffd9f194f125715693b7d49a7d9;01f826c943773c14b3600884b8f2737b5893dac3;main, 1 ahead / 0 behind, merge base exactly10f7874f309cb120bc57b8c0cb637d1292650fe0;src/outbound-fetch-policy.ts, newtest/outbound-request-body-inheritance.test.ts, andtest/outbound-request-compartment.test.ts.The two pre-existing current-main path blobs are byte-identical to #299's protected base before this delta (
src/outbound-fetch-policy.tsremained10f41fad67826f022c5599b5b83679366ff96a10across the #298 integration). The successor reuses #299's exact GREEN blobse9c20e05cbc8e61103fc06a4c787fdb9360bbbd3,b4d422710b3ac81d59ca198265c36d672a84cc20, andb0023769c548b0f304f68e90b0b3bc08b1939f87; all unrelated bytes come from current protectedmain.Security behavior
A body-bearing source
Requestcombined withRequestInit.body: nullor explicitundefinedmust not be treated as proof that the effective Fetch request has no body. The credential-egress policy therefore regards only non-null/non-undefinedRequestInit.bodyas an explicit body and otherwise falls back to the sourceRequest.body. Focused regressions require the body-bearing OIDC metadata cases to fail withblocked-request-policybefore the raw network function runs. No destination or method allowlist is broadened.Evidence boundary
#299's successful application CI, reviewer-ci and central Security Scan are predecessor evidence only and do not transfer. Keep this successor Draft until this unchanged exact head has fresh terminal-success application
ci,reviewer-ci, protected-base-eligible centralSecurity Scan, exact 100% owned production statement/branch/function/line coverage with realistic tests, and zero valid unresolved findings. Pending, queued, skipped, absent, neutral, failed, cancelled, stale, predecessor, status-only, model-only, or rate-limited evidence is non-passing.Immediately before Ready or merge, independently re-resolve protected
main, exact head/ref/ancestry, workflow checkout SHAs, live rulesets, central.githubSecurity Scan revision/triggers/base filters/thresholds, formal reviews, unresolved threads and active-writer state. Live ruleset18794436currently enforces only central.github/workflows/security-scan.yml@refs/heads/main, with no bypass actor and no independent formal-approval rule; do not synthesize approval authority.This change does not weaken gates, create repair/self-modifying workflows, publish/deploy, invent secrets/reviewers/evidence, or choose an outbound license.
Supersedes #299 only after fresh exact-head verification and protected integration.
Summary by CodeRabbit
버그 수정
RequestInit.body가null또는undefined로 지정된 경우에도 원본 요청의 민감한 본문이 잘못 상속되지 않도록 요청 본문 처리를 개선했습니다.502응답과 정책 차단을 나타내는 응답 헤더가 일관되게 반환됩니다.테스트