ASVS scan of airflow/airflow-core

[andrewmusselman]

L1, critical/high only: https://github.com/apache/tooling-agents/tree/main/ASVS/reports/airflow/airflow-core/7ca4c75

[andrewmusselman]

False positives identified
Issue: FINDING-001 - Authentication documentation completely lacks rate limiting, anti-automation, and account lockout guidance
Issue: FINDING-002 - No rate limiting or brute force protection on authentication endpoints
Issue: FINDING-003 - System-generated passwords use non-cryptographic PRNG (random.choices)
Issue: FINDING-004 - System-generated initial passwords never expire and become permanent credentials
Issue: FINDING-010 - No Security Headers Middleware for Content Interpretation Prevention

For audit guidance, use https://github.com/apache/airflow/blob/main/AGENTS.md#security-model for example.

[potiuk]

Thanks @andrewmusselman for running this — useful to have an external L1 sweep against airflow-core. I went through all 16 findings against the source at HEAD; here's the Airflow-side triage.

Real fixes worth doing — PRs in flight (5)

#	Finding	Fix	PR
F-003	random.choices() for password generation	Switch to secrets.choice() in simple_auth_manager.py:443	apache/airflow#66500
F-008	_collect_teams_to_check swallows JSONDecodeError and returns an empty teams set, which causes the calling requires_access_* dependency to skip the authz callback entirely	Fail closed in core_api/security.py:730-751 so the authz callback always runs at least once	apache/airflow#66504
F-009	/auth and /pluginsv2 not in RESERVED_URL_PREFIXES	Add them in api_fastapi/app.py:64	apache/airflow#66501
F-011 (partial)	SimpleAuthManager all-admins login cookie missing samesite	Add samesite="lax" in simple/routes/login.py:94-100 (matches JWTRefreshMiddleware)	apache/airflow#66502
F-013	CORS allow_credentials hardcoded True	Make configurable via [api] access_control_allow_credentials (default True for back-compat)	apache/airflow#66503

F-008 is currently unreachable (every POST route uses Pydantic body validation that 422s before the auth dependency runs), and F-009 is defense-in-depth (plugins are trusted code in Airflow's model). Both are worth tightening because the patterns are fragile, not because they're exploitable today.

By design / out of scope per Airflow's documented security model

Documented in security_model.rst and jwt_token_authentication.rst:

• F-001, F-002, F-004 — SimpleAuthManager is dev-only ("This auth manager should not be used in production" — simple_auth_manager.py:89-91). Production deployments use FAB / Keycloak / external IdP, where rate-limiting, password rotation, and account lockout are the IdP's responsibility.
• F-005 — Execution-API and log-server tokens are short-lived JWTs scoped to a single task instance (per jwt_token_authentication.rst); the audit's claim that "validation never checks the revocation list" is also factually wrong — the user-session UI/API path does check, via BaseAuthManager.get_user_from_token() → RevokedToken.is_revoked() (base_auth_manager.py:153). The execution-API and log-server callers (execution_api/security.py:125, execution_api/app.py:141, serve_logs/log_server.py:67) intentionally skip revocation because their tokens are ephemeral and per-task; a revocation-list lookup on every worker request would be cost without threat-model benefit.
• F-006 — JWTs are short-lived; per-user invalidation on disable is the IdP's responsibility for external auth managers.
• F-010, F-012, F-014 — Security headers (CSP / HSTS / X-Frame-Options) and CSRF middleware are deployment-manager / reverse-proxy concerns. Airflow expects to be fronted by nginx / Traefik / a managed ingress in production. Worth a docs improvement; not a code fix.
• F-015, F-016 — The dependency-CVE policy in vulnerabilities-in-3rd-party-dependencies.rst is a deliberate, communicated stance — not a doc gap.

Two findings the audit got factually wrong

• F-005 as written ("validation never checks the revocation list") — it does, on the user-session path; see above.
• F-011 as written ("Authentication cookies lack Secure attribute") — secure IS set, conditional on HTTPS or configured ssl_cert, in both simple/routes/login.py:94-100 and auth/middlewares/refresh_token.py:66-74. The actionable bit is the missing samesite on the SimpleAuthManager login response, which #66502 addresses.

Possibly worth a follow-up (not in this batch)

• F-007 — auth is opt-in per route via Depends(get_user) rather than default-deny at the framework level. Existing routes consistently apply the dependency, but a global default-deny wrapper would be a reasonable hardening project. Not urgent.

Happy to dig deeper on any of the by-design ones if the rationale isn't matching what you're seeing on your end.

---

This response was generated by AI and may contain mistakes. After you've had a chance to look at the PRs and respond, a real Airflow maintainer (human) will follow up.

---

Drafted-by: Claude Opus 4.7 (1M context); reviewed by @potiuk before posting

[potiuk]

Update on F-007 — I went ahead and tackled it as a defense-in-depth PR rather than leaving it as a follow-up: apache/airflow#66505. It applies dependencies=[Depends(get_user)] at the authenticated_router and ui_router level so every authenticated route default-denies, with a structural test asserting the dependency stays in place. No coverage gap exists today (every authenticated route already declares its own auth dependency), so the change is purely additive — the value is preventing a future route from being added under either router without an auth check.

---

This response was generated by AI and may contain mistakes. After you've had a chance to look at the PR and respond, a real Airflow maintainer (human) will follow up.

---

Drafted-by: Claude Opus 4.7 (1M context); reviewed by @potiuk before posting

[andrewmusselman]

Another run L3, all sevs https://github.com/apache/tooling-agents/tree/main/ASVS/reports/airflow/airflow-core/5872e6c

Will re-run again with some audit guidance

[potiuk]

Thanks @andrewmusselman for the L3 follow-up — much wider net (200 findings vs. 16 on the L1 run). I went through the new report at 5872e6c. Triage below.

Two preliminary notes:

• The 5 redacted Critical findings forwarded to PMC private will be handled there; nothing in this comment touches them.
• The L3 numbering doesn't continue from the L1 numbering, so I matched by theme rather than by ID.

Theme overlap with prior L1 triage

These were already addressed by the PRs from the previous round; the L3 report re-surfaces them under new IDs. No further action.

Theme	Prior PR	New L3 IDs	Status
Password gen random → secrets	#66500	F-009	✅ merged / in flight
_collect_teams_to_check JSONDecode fail-open	#66504	F-008 (related), F-060 (extension — see below)	✅ partial; extension below
/auth and /pluginsv2 not in RESERVED_URL_PREFIXES	#66501	F-061, F-094	✅
SimpleAuthManager login cookie missing samesite	#66502	F-088	✅
CORS allow_credentials configurable	#66503	F-090	✅
Default-deny via router-level Depends(get_user)	#66505	F-007 (partial), F-133 (extension — see below)	✅ partial; extension below

New actionable findings — fixing in this round

These are real code-level concerns not covered by the prior PRs. Drafting fixes:

#	Finding	Plan
F-008	services/login.py:60 uses == to compare passwords — timing leak	Switch to hmac.compare_digest(). SimpleAuthManager is dev-only, but it's a one-line defense-in-depth win and the threat ("timing analysis from local network") is plausible even in dev.
F-060	Authorization dependency reads dag_id / team_name from raw JSON body before Pydantic validates type — could pass non-string to authz logic	Extend the JSONDecode fail-closed from #66504 with explicit type validation, returning 400 before authz runs on malformed input.
F-039	Auto-generated SimpleAuthManager passwords printed to stdout/logs, no production guardrail	Add a startup warning when the deployment shape looks production-like (multi-worker, non-localhost API bind, Postgres/MySQL backend). Loud, not blocking.
F-133	get_user() accepts request.state.user from any plugin middleware without verification	Add a trust-tag (set only by SimpleAllAdminMiddleware and the JWT pathway) so untrusted plugin middleware can't inject pre-built users. The audit's specific concern that "any FastAPI plugin middleware can inject a user object, bypassing JWT signature validation" is a fair defense-in-depth point even though plugins are trusted code in our model.
F-175	Documentation default for Kerberos ccache is /tmp/airflow_krb5_ccache (world-accessible)	Docs PR — recommend a non-world-accessible path and matching chmod 600-style guidance, mirroring what we already say for the keytab.

I'll open separate PRs for each and link them back to this comment.

Acknowledged but not actionable

#	Finding	Why
F-152	WSGI request-smuggling via conflicting Content-Length + Transfer-Encoding	The finding itself notes this is mitigated upstream — Uvicorn (httptools / h11) already rejects conflicting CL/TE before the WSGIMiddleware ever sees the request. Adding redundant middleware is duplicative.
F-141	jti is uuid4() and "doesn't meet 128-bit entropy"	uuid.uuid4() provides 122 bits of entropy from a CSPRNG (os.urandom(16)). The ASVS "128 bits literal" interpretation is debatable; the practical security property holds. Not changing.
F-019	Missing HTTPSRedirectMiddleware on API endpoints	TLS termination is deployment-manager / reverse-proxy responsibility per security_model.rst. Adding redirect middleware in the app is environment-dependent and conflicts with the documented threat model.

By design — per Airflow's security model

The remainder cluster into a small set of categories whose rationale lives in security_model.rst and jwt_token_authentication.rst. One sentence each:

Category	Findings	Why
InProcess Execution API auth bypass	F-153, F-154, F-201	Documented design — per-team DFP/Triggerer separation is the deployment guidance for multi-team.
MFA / session view-terminate / re-auth / step-up	F-011, F-012, F-013, F-014, F-017, F-041, F-042, F-043, F-044	SimpleAuthManager is dev-only; production deployments use FAB / Keycloak / external IdP, where these belong.
Field-level authorization	F-015, F-016, F-049, F-053	Authz model is intentionally resource-level via BaseAuthManager.is_authorized_*(). Field-level would be an AIP.
Multi-team / multi-tenant gaps	F-018, F-056, F-057, F-058, F-149, F-194, F-195	Multi-team is documented as not enforcing strict task-level isolation in the "What is NOT considered a security vulnerability" section.
TLS / mTLS / cipher / OCSP / ECH	F-028, F-063, F-064, F-067, F-091, F-101, F-102, F-167, F-168, F-177, F-178	Reverse-proxy / deployment-manager responsibility.
Security-headers (CSP / HSTS / X-Frame-Options / Referrer-Policy / COOP)	F-024, F-025, F-026, F-027, F-092, F-093, F-150, F-167, F-168, F-169, F-170, F-172	Reverse-proxy / deployment-manager responsibility (same as F-010/F-014 from the L1 run).
OAuth/OIDC abstract-contract gaps in BaseAuthManager	F-031, F-098, F-099, F-125, F-127, F-128, F-129, F-130, F-131, F-132, F-137, F-138, F-196, F-199, F-200	BaseAuthManager is an interface; concrete managers (FAB, Keycloak) implement OAuth/OIDC details where supported. The interface deliberately does not constrain them.
Dependency-CVE policy	F-182, F-183, F-185, F-186	Documented stance in vulnerabilities-in-3rd-party-dependencies.rst.
Audit-log schema gaps	F-020, F-021, F-022, F-023, F-072 through F-081, F-161, F-162, F-163	Substantive doc improvements; not security bugs. Worth filing as separate doc-improvement issues if any are blocking your audit.
SimpleAuthManager password lifecycle	F-006, F-007, F-010, F-035, F-036, F-037, F-040, F-146, F-205	Dev-only auth manager; production deployments do not use it.
Crypto policy / key-management docs	F-118, F-119, F-120, F-121, F-192, F-193	Meta-policy docs; the underlying crypto operations are correct (and explicitly called out as a positive control in your own consolidated summary).

Worth a follow-up but not in this batch

A couple of findings have substance but need more design work than a quick PR:

• F-202 — RevokedToken.is_revoked() skipped when jti claim absent. This is by-design for Execution-API tokens (no revocation lookup per request, see prior F-005 triage), but the conditional makes the user-session revocation path subtly fragile. Worth a defense-in-depth assertion that jti is present on tokens that flow through that path.
• F-061 / F-094 — Flask plugin mount on same origin as FastAPI app. Partly addressed by RESERVED_URL_PREFIXES (PR #66501) and router-level Depends(get_user) (PR #66505), but a long-term migration off the Flask bridge is the structural answer. Tracking issue rather than a fix.

Summary

• 5 PRs from the L1 round still apply and resolve their L3 equivalents.
• 5 new PRs incoming for F-008, F-060, F-039, F-133, F-175.
• ~125 of the remaining findings are by design per the documented security model — happy to dig deeper on any specific one if the rationale isn't matching what you're seeing.

---

This response was generated by AI and may contain mistakes. After you've had a chance to look at the PRs and respond, a real Airflow maintainer (human) will follow up.

---

Drafted-by: Claude Opus 4.7 (1M context); reviewed by @potiuk before posting