noCV
AFETCH-104 · Bound remote work

Revalidate every document redirect before following it

Practice briefBugAdvanced

An approved download host redirects to an unapproved internal URL after the first request passes validation.

Focused work estimate
3h 30m + prerequisites
Priority in the scenario
High
Engineering practice
HTTP security · Redirect handling

Estimated field mix

  • Security60%
  • Networking40%

Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence.

Your next step

Review it, then add it to your workspace.

The board opens an editable draft; nothing is saved until you confirm it. Sign-in and workspace permissions apply, and Demo boards remain ephemeral.

Project context

A fictional knowledge service imports documents from customer-entered URLs. The importer follows redirects and trusts response metadata too broadly.

Setup prerequisites

  • Build a local fetch adapter and controlled HTTP test servers.
  • Use synthetic documents and deny network access outside the test allowlist.

Preceding work

Complete these dependencies, or supply their agreed outputs before taking this ticket.

Acceptance criteria

  • Limit redirect count and validate each target independently.
  • Do not forward credentials across origins.
  • Reject redirect loops with a stable reason code.

Implementation constraints

  • Use local controlled redirect fixtures only.

Verification to include

  • Follow one permitted same-policy redirect.
  • Redirect toward an internal fixture address and assert it is blocked before connection.

Deliverables

  • Redirect policy and credential-stripping regression

Rollout and recovery

Enable bounded redirect handling; disable redirect support if a client bypasses target validation.

Value of the work

For the engineer: Practice defensive URL handling and bounded untrusted-input processing.

For the team: Review whether integrations can import content without expanding infrastructure access.

Evidence boundaries

Outcome Evidence: Tests, patches, and runbooks are requested deliverables. They become Outcome Evidence only through a qualified Mission and immutable Evidence IDs.

Ownership Evidence: Independent adaptation must be observed under a declared verification policy and cite immutable Evidence IDs. Completing a planning ticket establishes no Ownership Evidence.