Enforce ti:self scope on /execution/task-reschedules/{ti}/start_date

[potiuk]

Three sibling per-task-instance routers under airflow.api_fastapi.execution_api.routes opt into the ti:self JWT scope, which "verifies that the token's sub claim matches the {task_instance_id} path parameter, preventing a worker from accessing another task's endpoints" (per security/jwt_token_authentication.html): task_instances.py, hitl.py, and task_state.py. The task_reschedules.py router for GET /execution/task-reschedules/{task_instance_id}/start_date was missing that scope, so any authenticated worker could read the first reschedule timestamp of any task instance in the deployment by passing that task instance's UUID in the URL path.

This change adds the standard dependencies=[Security(require_auth, scopes=["ti:self"])] to the router declaration — the same pattern the three sibling routers already use. One new regression test under TestGetRescheduleStartDate exercises the mismatched-subject path and asserts 403.

Acknowledgement

Thanks to Harish Kolla (independent security researcher, GitHub @Har1sh-k) for reporting the missing scope enforcement on this endpoint, which prompted this hardening change.

Test plan

• New regression test test_mismatched_subject_is_rejected asserts a mismatched JWT subject is rejected with 403 on the concrete route.
• Existing TestGetRescheduleStartDate tests still pass (the conftest client fixture auto-matches the JWT subject to the path parameter, so happy-path tests are unaffected).
• prek run --from-ref main --to-ref HEAD --stage pre-commit clean on touched files.
• prek run --from-ref main --to-ref HEAD --stage manual clean on touched files.

Was generative AI tooling used to co-author this PR?

• Yes — Claude Opus 4.7 (1M context)

Generated-by: Claude Opus 4.7 (1M context) following the guidelines at https://github.com/apache/airflow/blob/main/contributing-docs/05_pull_requests.rst#gen-ai-assisted-contributions

[ashb]

As i said before: We should also add a dual to existing test_ti_self_routes_have_task_instance_id_param that tests that all routes with {task_instance_id} param in them either have ti:self or an explicit exclusion.

That is a much more useful test than re-testing the effect of the scope on one end point

[potiuk]

Done — replaced the per-endpoint test with the structural dual you described. test_routes_with_task_instance_id_param_enforce_ti_self now asserts every operation exposing a {task_instance_id} path param requires the ti:self scope (or is on an explicit, currently-empty TI_ID_ROUTES_WITHOUT_TI_SELF allowlist), and dropped test_mismatched_subject_is_rejected.

One implementation note: I couldn't do it by walking app.routes like the existing forward test — the execution API assembles routes per version, so in the test harness static route introspection only surfaces a single top-level route. So it checks the served OpenAPI spec (security per operation) across every version in the bundle instead. Verified it's non-vacuous (12 such paths) and that it actually catches the gap: reverting the ti:self dependency makes it fail, listing GET /task-reschedules/{task_instance_id}/start_date across all versions.

Side note from that: the existing test_ti_self_routes_have_task_instance_id_param (forward direction) appears to be effectively vacuous for the same route-introspection reason — happy to convert it to the OpenAPI approach in a follow-up if you agree.

---

Drafted-by: Claude Code (Opus 4.8); reviewed by @potiuk before posting

[potiuk]

@ashb — circling back: the structural dual you asked for went in on the 5th (test_routes_with_task_instance_id_param_enforce_ti_self) — it walks every {task_instance_id} operation across all API versions and asserts each carries ti:self or sits in an explicit TI_ID_ROUTES_WITHOUT_TI_SELF exclusion set. PR's mergeable + green. Could you take another look / clear the change-request? Thanks!

[potiuk]

Crediting the reporter: thanks to Harish Kolla (independent security researcher, GitHub @Har1sh-k) for reporting the missing ti:self scope enforcement on GET /execution/task-reschedules/{task_instance_id}/start_date that prompted this hardening change. 🙏

[potiuk]

Three sibling per-task-instance routers under airflow.api_fastapi.execution_api.routes opt into the ti:self JWT scope, which "verifies that the token's sub claim matches the {task_instance_id} path parameter, preventing a worker from accessing another task's endpoints" (per security/jwt_token_authentication.html): task_instances.py, hitl.py, and task_state.py. The task_reschedules.py router for GET /execution/task-reschedules/{task_instance_id}/start_date was missing that scope, so any authenticated worker could read the first reschedule timestamp of any task instance in the deployment by passing that task instance's UUID in the URL path.

This change adds the standard dependencies=[Security(require_auth, scopes=["ti:self"])] to the router declaration — the same pattern the three sibling routers already use. One new regression test under TestGetRescheduleStartDate exercises the mismatched-subject path and asserts 403.

Acknowledgement

Thanks to Harish Kolla (independent security researcher, GitHub @Har1sh-k) for reporting the missing scope enforcement on this endpoint, which prompted this hardening change.

Test plan

• New regression test test_mismatched_subject_is_rejected asserts a mismatched JWT subject is rejected with 403 on the concrete route.
• Existing TestGetRescheduleStartDate tests still pass (the conftest client fixture auto-matches the JWT subject to the path parameter, so happy-path tests are unaffected).
• prek run --from-ref main --to-ref HEAD --stage pre-commit clean on touched files.
• prek run --from-ref main --to-ref HEAD --stage manual clean on touched files.

Was generative AI tooling used to co-author this PR?

• Yes — Claude Opus 4.7 (1M context)

Generated-by: Claude Opus 4.7 (1M context) following the guidelines at https://github.com/apache/airflow/blob/main/contributing-docs/05_pull_requests.rst#gen-ai-assisted-contributions

[ashb]

As i said before: We should also add a dual to existing test_ti_self_routes_have_task_instance_id_param that tests that all routes with {task_instance_id} param in them either have ti:self or an explicit exclusion.

That is a much more useful test than re-testing the effect of the scope on one end point

[potiuk]

Done — replaced the per-endpoint test with the structural dual you described. test_routes_with_task_instance_id_param_enforce_ti_self now asserts every operation exposing a {task_instance_id} path param requires the ti:self scope (or is on an explicit, currently-empty TI_ID_ROUTES_WITHOUT_TI_SELF allowlist), and dropped test_mismatched_subject_is_rejected.

One implementation note: I couldn't do it by walking app.routes like the existing forward test — the execution API assembles routes per version, so in the test harness static route introspection only surfaces a single top-level route. So it checks the served OpenAPI spec (security per operation) across every version in the bundle instead. Verified it's non-vacuous (12 such paths) and that it actually catches the gap: reverting the ti:self dependency makes it fail, listing GET /task-reschedules/{task_instance_id}/start_date across all versions.

Side note from that: the existing test_ti_self_routes_have_task_instance_id_param (forward direction) appears to be effectively vacuous for the same route-introspection reason — happy to convert it to the OpenAPI approach in a follow-up if you agree.

---

Drafted-by: Claude Code (Opus 4.8); reviewed by @potiuk before posting

[potiuk]

@ashb — circling back: the structural dual you asked for went in on the 5th (test_routes_with_task_instance_id_param_enforce_ti_self) — it walks every {task_instance_id} operation across all API versions and asserts each carries ti:self or sits in an explicit TI_ID_ROUTES_WITHOUT_TI_SELF exclusion set. PR's mergeable + green. Could you take another look / clear the change-request? Thanks!

[potiuk]

Crediting the reporter: thanks to Harish Kolla (independent security researcher, GitHub @Har1sh-k) for reporting the missing ti:self scope enforcement on GET /execution/task-reschedules/{task_instance_id}/start_date that prompted this hardening change. 🙏

[potiuk]

Three sibling per-task-instance routers under airflow.api_fastapi.execution_api.routes opt into the ti:self JWT scope, which "verifies that the token's sub claim matches the {task_instance_id} path parameter, preventing a worker from accessing another task's endpoints" (per security/jwt_token_authentication.html): task_instances.py, hitl.py, and task_state.py. The task_reschedules.py router for GET /execution/task-reschedules/{task_instance_id}/start_date was missing that scope, so any authenticated worker could read the first reschedule timestamp of any task instance in the deployment by passing that task instance's UUID in the URL path.

This change adds the standard dependencies=[Security(require_auth, scopes=["ti:self"])] to the router declaration — the same pattern the three sibling routers already use. One new regression test under TestGetRescheduleStartDate exercises the mismatched-subject path and asserts 403.

Acknowledgement

Thanks to Harish Kolla (independent security researcher, GitHub @Har1sh-k) for reporting the missing scope enforcement on this endpoint, which prompted this hardening change.

Test plan

• New regression test test_mismatched_subject_is_rejected asserts a mismatched JWT subject is rejected with 403 on the concrete route.
• Existing TestGetRescheduleStartDate tests still pass (the conftest client fixture auto-matches the JWT subject to the path parameter, so happy-path tests are unaffected).
• prek run --from-ref main --to-ref HEAD --stage pre-commit clean on touched files.
• prek run --from-ref main --to-ref HEAD --stage manual clean on touched files.

Was generative AI tooling used to co-author this PR?

• Yes — Claude Opus 4.7 (1M context)

Generated-by: Claude Opus 4.7 (1M context) following the guidelines at https://github.com/apache/airflow/blob/main/contributing-docs/05_pull_requests.rst#gen-ai-assisted-contributions

[ashb]

As i said before: We should also add a dual to existing test_ti_self_routes_have_task_instance_id_param that tests that all routes with {task_instance_id} param in them either have ti:self or an explicit exclusion.

That is a much more useful test than re-testing the effect of the scope on one end point

[potiuk]

Done — replaced the per-endpoint test with the structural dual you described. test_routes_with_task_instance_id_param_enforce_ti_self now asserts every operation exposing a {task_instance_id} path param requires the ti:self scope (or is on an explicit, currently-empty TI_ID_ROUTES_WITHOUT_TI_SELF allowlist), and dropped test_mismatched_subject_is_rejected.

One implementation note: I couldn't do it by walking app.routes like the existing forward test — the execution API assembles routes per version, so in the test harness static route introspection only surfaces a single top-level route. So it checks the served OpenAPI spec (security per operation) across every version in the bundle instead. Verified it's non-vacuous (12 such paths) and that it actually catches the gap: reverting the ti:self dependency makes it fail, listing GET /task-reschedules/{task_instance_id}/start_date across all versions.

Side note from that: the existing test_ti_self_routes_have_task_instance_id_param (forward direction) appears to be effectively vacuous for the same route-introspection reason — happy to convert it to the OpenAPI approach in a follow-up if you agree.

---

Drafted-by: Claude Code (Opus 4.8); reviewed by @potiuk before posting

[potiuk]

@ashb — circling back: the structural dual you asked for went in on the 5th (test_routes_with_task_instance_id_param_enforce_ti_self) — it walks every {task_instance_id} operation across all API versions and asserts each carries ti:self or sits in an explicit TI_ID_ROUTES_WITHOUT_TI_SELF exclusion set. PR's mergeable + green. Could you take another look / clear the change-request? Thanks!

[potiuk]

Crediting the reporter: thanks to Harish Kolla (independent security researcher, GitHub @Har1sh-k) for reporting the missing ti:self scope enforcement on GET /execution/task-reschedules/{task_instance_id}/start_date that prompted this hardening change. 🙏

[potiuk]

Three sibling per-task-instance routers under airflow.api_fastapi.execution_api.routes opt into the ti:self JWT scope, which "verifies that the token's sub claim matches the {task_instance_id} path parameter, preventing a worker from accessing another task's endpoints" (per security/jwt_token_authentication.html): task_instances.py, hitl.py, and task_state.py. The task_reschedules.py router for GET /execution/task-reschedules/{task_instance_id}/start_date was missing that scope, so any authenticated worker could read the first reschedule timestamp of any task instance in the deployment by passing that task instance's UUID in the URL path.

This change adds the standard dependencies=[Security(require_auth, scopes=["ti:self"])] to the router declaration — the same pattern the three sibling routers already use. One new regression test under TestGetRescheduleStartDate exercises the mismatched-subject path and asserts 403.

Acknowledgement

Thanks to Harish Kolla (independent security researcher, GitHub @Har1sh-k) for reporting the missing scope enforcement on this endpoint, which prompted this hardening change.

Test plan

• New regression test test_mismatched_subject_is_rejected asserts a mismatched JWT subject is rejected with 403 on the concrete route.
• Existing TestGetRescheduleStartDate tests still pass (the conftest client fixture auto-matches the JWT subject to the path parameter, so happy-path tests are unaffected).
• prek run --from-ref main --to-ref HEAD --stage pre-commit clean on touched files.
• prek run --from-ref main --to-ref HEAD --stage manual clean on touched files.

Was generative AI tooling used to co-author this PR?

• Yes — Claude Opus 4.7 (1M context)

Generated-by: Claude Opus 4.7 (1M context) following the guidelines at https://github.com/apache/airflow/blob/main/contributing-docs/05_pull_requests.rst#gen-ai-assisted-contributions

[ashb]

As i said before: We should also add a dual to existing test_ti_self_routes_have_task_instance_id_param that tests that all routes with {task_instance_id} param in them either have ti:self or an explicit exclusion.

That is a much more useful test than re-testing the effect of the scope on one end point

[potiuk]

Done — replaced the per-endpoint test with the structural dual you described. test_routes_with_task_instance_id_param_enforce_ti_self now asserts every operation exposing a {task_instance_id} path param requires the ti:self scope (or is on an explicit, currently-empty TI_ID_ROUTES_WITHOUT_TI_SELF allowlist), and dropped test_mismatched_subject_is_rejected.

One implementation note: I couldn't do it by walking app.routes like the existing forward test — the execution API assembles routes per version, so in the test harness static route introspection only surfaces a single top-level route. So it checks the served OpenAPI spec (security per operation) across every version in the bundle instead. Verified it's non-vacuous (12 such paths) and that it actually catches the gap: reverting the ti:self dependency makes it fail, listing GET /task-reschedules/{task_instance_id}/start_date across all versions.

Side note from that: the existing test_ti_self_routes_have_task_instance_id_param (forward direction) appears to be effectively vacuous for the same route-introspection reason — happy to convert it to the OpenAPI approach in a follow-up if you agree.

---

Drafted-by: Claude Code (Opus 4.8); reviewed by @potiuk before posting

[potiuk]

@ashb — circling back: the structural dual you asked for went in on the 5th (test_routes_with_task_instance_id_param_enforce_ti_self) — it walks every {task_instance_id} operation across all API versions and asserts each carries ti:self or sits in an explicit TI_ID_ROUTES_WITHOUT_TI_SELF exclusion set. PR's mergeable + green. Could you take another look / clear the change-request? Thanks!

[potiuk]

Crediting the reporter: thanks to Harish Kolla (independent security researcher, GitHub @Har1sh-k) for reporting the missing ti:self scope enforcement on GET /execution/task-reschedules/{task_instance_id}/start_date that prompted this hardening change. 🙏

[potiuk]

Three sibling per-task-instance routers under airflow.api_fastapi.execution_api.routes opt into the ti:self JWT scope, which "verifies that the token's sub claim matches the {task_instance_id} path parameter, preventing a worker from accessing another task's endpoints" (per security/jwt_token_authentication.html): task_instances.py, hitl.py, and task_state.py. The task_reschedules.py router for GET /execution/task-reschedules/{task_instance_id}/start_date was missing that scope, so any authenticated worker could read the first reschedule timestamp of any task instance in the deployment by passing that task instance's UUID in the URL path.

This change adds the standard dependencies=[Security(require_auth, scopes=["ti:self"])] to the router declaration — the same pattern the three sibling routers already use. One new regression test under TestGetRescheduleStartDate exercises the mismatched-subject path and asserts 403.

Acknowledgement

Thanks to Harish Kolla (independent security researcher, GitHub @Har1sh-k) for reporting the missing scope enforcement on this endpoint, which prompted this hardening change.

Test plan

• New regression test test_mismatched_subject_is_rejected asserts a mismatched JWT subject is rejected with 403 on the concrete route.
• Existing TestGetRescheduleStartDate tests still pass (the conftest client fixture auto-matches the JWT subject to the path parameter, so happy-path tests are unaffected).
• prek run --from-ref main --to-ref HEAD --stage pre-commit clean on touched files.
• prek run --from-ref main --to-ref HEAD --stage manual clean on touched files.

Was generative AI tooling used to co-author this PR?

• Yes — Claude Opus 4.7 (1M context)

Generated-by: Claude Opus 4.7 (1M context) following the guidelines at https://github.com/apache/airflow/blob/main/contributing-docs/05_pull_requests.rst#gen-ai-assisted-contributions

[ashb]

As i said before: We should also add a dual to existing test_ti_self_routes_have_task_instance_id_param that tests that all routes with {task_instance_id} param in them either have ti:self or an explicit exclusion.

That is a much more useful test than re-testing the effect of the scope on one end point

[potiuk]

Done — replaced the per-endpoint test with the structural dual you described. test_routes_with_task_instance_id_param_enforce_ti_self now asserts every operation exposing a {task_instance_id} path param requires the ti:self scope (or is on an explicit, currently-empty TI_ID_ROUTES_WITHOUT_TI_SELF allowlist), and dropped test_mismatched_subject_is_rejected.

One implementation note: I couldn't do it by walking app.routes like the existing forward test — the execution API assembles routes per version, so in the test harness static route introspection only surfaces a single top-level route. So it checks the served OpenAPI spec (security per operation) across every version in the bundle instead. Verified it's non-vacuous (12 such paths) and that it actually catches the gap: reverting the ti:self dependency makes it fail, listing GET /task-reschedules/{task_instance_id}/start_date across all versions.

Side note from that: the existing test_ti_self_routes_have_task_instance_id_param (forward direction) appears to be effectively vacuous for the same route-introspection reason — happy to convert it to the OpenAPI approach in a follow-up if you agree.

---

Drafted-by: Claude Code (Opus 4.8); reviewed by @potiuk before posting

[potiuk]

@ashb — circling back: the structural dual you asked for went in on the 5th (test_routes_with_task_instance_id_param_enforce_ti_self) — it walks every {task_instance_id} operation across all API versions and asserts each carries ti:self or sits in an explicit TI_ID_ROUTES_WITHOUT_TI_SELF exclusion set. PR's mergeable + green. Could you take another look / clear the change-request? Thanks!

[potiuk]

Crediting the reporter: thanks to Harish Kolla (independent security researcher, GitHub @Har1sh-k) for reporting the missing ti:self scope enforcement on GET /execution/task-reschedules/{task_instance_id}/start_date that prompted this hardening change. 🙏

[potiuk]

Three sibling per-task-instance routers under airflow.api_fastapi.execution_api.routes opt into the ti:self JWT scope, which "verifies that the token's sub claim matches the {task_instance_id} path parameter, preventing a worker from accessing another task's endpoints" (per security/jwt_token_authentication.html): task_instances.py, hitl.py, and task_state.py. The task_reschedules.py router for GET /execution/task-reschedules/{task_instance_id}/start_date was missing that scope, so any authenticated worker could read the first reschedule timestamp of any task instance in the deployment by passing that task instance's UUID in the URL path.

This change adds the standard dependencies=[Security(require_auth, scopes=["ti:self"])] to the router declaration — the same pattern the three sibling routers already use. One new regression test under TestGetRescheduleStartDate exercises the mismatched-subject path and asserts 403.

Acknowledgement

Thanks to Harish Kolla (independent security researcher, GitHub @Har1sh-k) for reporting the missing scope enforcement on this endpoint, which prompted this hardening change.

Test plan

• New regression test test_mismatched_subject_is_rejected asserts a mismatched JWT subject is rejected with 403 on the concrete route.
• Existing TestGetRescheduleStartDate tests still pass (the conftest client fixture auto-matches the JWT subject to the path parameter, so happy-path tests are unaffected).
• prek run --from-ref main --to-ref HEAD --stage pre-commit clean on touched files.
• prek run --from-ref main --to-ref HEAD --stage manual clean on touched files.

Was generative AI tooling used to co-author this PR?

• Yes — Claude Opus 4.7 (1M context)

Generated-by: Claude Opus 4.7 (1M context) following the guidelines at https://github.com/apache/airflow/blob/main/contributing-docs/05_pull_requests.rst#gen-ai-assisted-contributions

[ashb]

As i said before: We should also add a dual to existing test_ti_self_routes_have_task_instance_id_param that tests that all routes with {task_instance_id} param in them either have ti:self or an explicit exclusion.

That is a much more useful test than re-testing the effect of the scope on one end point

[potiuk]

Done — replaced the per-endpoint test with the structural dual you described. test_routes_with_task_instance_id_param_enforce_ti_self now asserts every operation exposing a {task_instance_id} path param requires the ti:self scope (or is on an explicit, currently-empty TI_ID_ROUTES_WITHOUT_TI_SELF allowlist), and dropped test_mismatched_subject_is_rejected.

One implementation note: I couldn't do it by walking app.routes like the existing forward test — the execution API assembles routes per version, so in the test harness static route introspection only surfaces a single top-level route. So it checks the served OpenAPI spec (security per operation) across every version in the bundle instead. Verified it's non-vacuous (12 such paths) and that it actually catches the gap: reverting the ti:self dependency makes it fail, listing GET /task-reschedules/{task_instance_id}/start_date across all versions.

Side note from that: the existing test_ti_self_routes_have_task_instance_id_param (forward direction) appears to be effectively vacuous for the same route-introspection reason — happy to convert it to the OpenAPI approach in a follow-up if you agree.

---

Drafted-by: Claude Code (Opus 4.8); reviewed by @potiuk before posting

[potiuk]

@ashb — circling back: the structural dual you asked for went in on the 5th (test_routes_with_task_instance_id_param_enforce_ti_self) — it walks every {task_instance_id} operation across all API versions and asserts each carries ti:self or sits in an explicit TI_ID_ROUTES_WITHOUT_TI_SELF exclusion set. PR's mergeable + green. Could you take another look / clear the change-request? Thanks!

[potiuk]

Crediting the reporter: thanks to Harish Kolla (independent security researcher, GitHub @Har1sh-k) for reporting the missing ti:self scope enforcement on GET /execution/task-reschedules/{task_instance_id}/start_date that prompted this hardening change. 🙏

[potiuk]

Three sibling per-task-instance routers under airflow.api_fastapi.execution_api.routes opt into the ti:self JWT scope, which "verifies that the token's sub claim matches the {task_instance_id} path parameter, preventing a worker from accessing another task's endpoints" (per security/jwt_token_authentication.html): task_instances.py, hitl.py, and task_state.py. The task_reschedules.py router for GET /execution/task-reschedules/{task_instance_id}/start_date was missing that scope, so any authenticated worker could read the first reschedule timestamp of any task instance in the deployment by passing that task instance's UUID in the URL path.

This change adds the standard dependencies=[Security(require_auth, scopes=["ti:self"])] to the router declaration — the same pattern the three sibling routers already use. One new regression test under TestGetRescheduleStartDate exercises the mismatched-subject path and asserts 403.

Acknowledgement

Thanks to Harish Kolla (independent security researcher, GitHub @Har1sh-k) for reporting the missing scope enforcement on this endpoint, which prompted this hardening change.

Test plan

• New regression test test_mismatched_subject_is_rejected asserts a mismatched JWT subject is rejected with 403 on the concrete route.
• Existing TestGetRescheduleStartDate tests still pass (the conftest client fixture auto-matches the JWT subject to the path parameter, so happy-path tests are unaffected).
• prek run --from-ref main --to-ref HEAD --stage pre-commit clean on touched files.
• prek run --from-ref main --to-ref HEAD --stage manual clean on touched files.

Was generative AI tooling used to co-author this PR?

• Yes — Claude Opus 4.7 (1M context)

Generated-by: Claude Opus 4.7 (1M context) following the guidelines at https://github.com/apache/airflow/blob/main/contributing-docs/05_pull_requests.rst#gen-ai-assisted-contributions

[ashb]

As i said before: We should also add a dual to existing test_ti_self_routes_have_task_instance_id_param that tests that all routes with {task_instance_id} param in them either have ti:self or an explicit exclusion.

That is a much more useful test than re-testing the effect of the scope on one end point

[potiuk]

Done — replaced the per-endpoint test with the structural dual you described. test_routes_with_task_instance_id_param_enforce_ti_self now asserts every operation exposing a {task_instance_id} path param requires the ti:self scope (or is on an explicit, currently-empty TI_ID_ROUTES_WITHOUT_TI_SELF allowlist), and dropped test_mismatched_subject_is_rejected.

One implementation note: I couldn't do it by walking app.routes like the existing forward test — the execution API assembles routes per version, so in the test harness static route introspection only surfaces a single top-level route. So it checks the served OpenAPI spec (security per operation) across every version in the bundle instead. Verified it's non-vacuous (12 such paths) and that it actually catches the gap: reverting the ti:self dependency makes it fail, listing GET /task-reschedules/{task_instance_id}/start_date across all versions.

Side note from that: the existing test_ti_self_routes_have_task_instance_id_param (forward direction) appears to be effectively vacuous for the same route-introspection reason — happy to convert it to the OpenAPI approach in a follow-up if you agree.

---

Drafted-by: Claude Code (Opus 4.8); reviewed by @potiuk before posting

[potiuk]

@ashb — circling back: the structural dual you asked for went in on the 5th (test_routes_with_task_instance_id_param_enforce_ti_self) — it walks every {task_instance_id} operation across all API versions and asserts each carries ti:self or sits in an explicit TI_ID_ROUTES_WITHOUT_TI_SELF exclusion set. PR's mergeable + green. Could you take another look / clear the change-request? Thanks!

[potiuk]

Crediting the reporter: thanks to Harish Kolla (independent security researcher, GitHub @Har1sh-k) for reporting the missing ti:self scope enforcement on GET /execution/task-reschedules/{task_instance_id}/start_date that prompted this hardening change. 🙏

[potiuk]

Three sibling per-task-instance routers under airflow.api_fastapi.execution_api.routes opt into the ti:self JWT scope, which "verifies that the token's sub claim matches the {task_instance_id} path parameter, preventing a worker from accessing another task's endpoints" (per security/jwt_token_authentication.html): task_instances.py, hitl.py, and task_state.py. The task_reschedules.py router for GET /execution/task-reschedules/{task_instance_id}/start_date was missing that scope, so any authenticated worker could read the first reschedule timestamp of any task instance in the deployment by passing that task instance's UUID in the URL path.

This change adds the standard dependencies=[Security(require_auth, scopes=["ti:self"])] to the router declaration — the same pattern the three sibling routers already use. One new regression test under TestGetRescheduleStartDate exercises the mismatched-subject path and asserts 403.

Acknowledgement

Thanks to Harish Kolla (independent security researcher, GitHub @Har1sh-k) for reporting the missing scope enforcement on this endpoint, which prompted this hardening change.

Test plan

• New regression test test_mismatched_subject_is_rejected asserts a mismatched JWT subject is rejected with 403 on the concrete route.
• Existing TestGetRescheduleStartDate tests still pass (the conftest client fixture auto-matches the JWT subject to the path parameter, so happy-path tests are unaffected).
• prek run --from-ref main --to-ref HEAD --stage pre-commit clean on touched files.
• prek run --from-ref main --to-ref HEAD --stage manual clean on touched files.

Was generative AI tooling used to co-author this PR?

• Yes — Claude Opus 4.7 (1M context)

Generated-by: Claude Opus 4.7 (1M context) following the guidelines at https://github.com/apache/airflow/blob/main/contributing-docs/05_pull_requests.rst#gen-ai-assisted-contributions

[ashb]

As i said before: We should also add a dual to existing test_ti_self_routes_have_task_instance_id_param that tests that all routes with {task_instance_id} param in them either have ti:self or an explicit exclusion.

That is a much more useful test than re-testing the effect of the scope on one end point

[potiuk]

Done — replaced the per-endpoint test with the structural dual you described. test_routes_with_task_instance_id_param_enforce_ti_self now asserts every operation exposing a {task_instance_id} path param requires the ti:self scope (or is on an explicit, currently-empty TI_ID_ROUTES_WITHOUT_TI_SELF allowlist), and dropped test_mismatched_subject_is_rejected.

One implementation note: I couldn't do it by walking app.routes like the existing forward test — the execution API assembles routes per version, so in the test harness static route introspection only surfaces a single top-level route. So it checks the served OpenAPI spec (security per operation) across every version in the bundle instead. Verified it's non-vacuous (12 such paths) and that it actually catches the gap: reverting the ti:self dependency makes it fail, listing GET /task-reschedules/{task_instance_id}/start_date across all versions.

Side note from that: the existing test_ti_self_routes_have_task_instance_id_param (forward direction) appears to be effectively vacuous for the same route-introspection reason — happy to convert it to the OpenAPI approach in a follow-up if you agree.

---

Drafted-by: Claude Code (Opus 4.8); reviewed by @potiuk before posting

[potiuk]

@ashb — circling back: the structural dual you asked for went in on the 5th (test_routes_with_task_instance_id_param_enforce_ti_self) — it walks every {task_instance_id} operation across all API versions and asserts each carries ti:self or sits in an explicit TI_ID_ROUTES_WITHOUT_TI_SELF exclusion set. PR's mergeable + green. Could you take another look / clear the change-request? Thanks!

[potiuk]

Crediting the reporter: thanks to Harish Kolla (independent security researcher, GitHub @Har1sh-k) for reporting the missing ti:self scope enforcement on GET /execution/task-reschedules/{task_instance_id}/start_date that prompted this hardening change. 🙏