[potiuk]

DEFAULT_SENSITIVE_FIELDS is the allowlist used by the secrets masker for
masking Variables and Connection extras. Several common field names used by
official Airflow providers and standard HTTP/database configurations are
not in the allowlist.

This PR adds five field names commonly used in connection extras and
provider configurations:

• webhook_url — Slack provider webhook URL key
• bearer — HTTP bearer-token auth key
• dsn — database connection strings (which typically embed credentials, e.g. postgres://user:pass@host/db)
• auth_header — custom HTTP auth header values
• service_key — service-account-like keys

The matcher uses case-insensitive substring matching, so e.g. bearer covers
Bearer, bearer_token, auth_bearer, etc.

Related: https://github.com/airflow-s/airflow-s/issues/377

Test plan

• uv run --project shared/secrets_masker pytest shared/secrets_masker/tests/ -xvs — secrets-masker tests pass
• New parametrised test asserts should_hide_value_for_key(name) returns True for each of the five new field names plus substring variants (WEBHOOK_URL, slack_webhook_url, auth_bearer, AUTH_HEADER, custom_auth_header, my_service_key)

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

[amoghrajesh]

Thanks for adding this.

One thing worth considering is that providers already declare which extra fields are sensitive via "format": "password" in provider.yaml conn-fieldsand ProvidersManager already tracks this as is_sensitive=True on each ConnectionFormWidgetInfo. If we can get the secrets masker to read that and add it in, this whole process could be automated.

That way any provider that correctly declares a password field gets it masked automatically, without needing manual additions to the core allowlist.

[vatsrahul1001]

Thanks for adding this.

One thing worth considering is that providers already declare which extra fields are sensitive via "format": "password" in provider.yaml conn-fieldsand ProvidersManager already tracks this as is_sensitive=True on each ConnectionFormWidgetInfo. If we can get the secrets masker to read that and add it in, this whole process could be automated.

That way any provider that correctly declares a password field gets it masked automatically, without needing manual additions to the core allowlist.

This can be in follow PR right @amoghrajesh ?

[amoghrajesh]

Totally, rest for follow up

[github-actions]

Backport successfully created: v3-2-test

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
✅	v3-2-test