Unmask values in UI variables export

[steveahnahn]

Summary

Fixed variable export functionality in the Airflow UI to return unmasked/real values instead of masked values (***), and added admin/elevated access protection to ensure only authorized users can export unmasked values.

Problem

This problem occurred because the UI was downloading cached data from the GET endpoint which uses VariableResponse model that masks sensitive fields. CLI export worked correctly because it directly accesses the database without masking

Solution

Created a new dedicated export endpoint with proper security controls. Requires OP level access as it grants controls over editing variables

• Changed export button to call new VariableService.exportVariables() API

Test

Added test_export_variables_with_unmasked_values that verifies password variables export with real values

Related Issue

Fixes #57428

[pierrejeambrun]

We had a discussion in the team recently for that.

@potiuk @ashb WDYT, should we allow this? (sorry our last thread was so long I can't remember if we settled on this particular use case)

(Anyone with "Write" permission on variables will be able to export them with sensitive fields unredated)

[ashb]

I don't think our permissions model has the distinction, but I think it should need more than just write permission on connections to be able to export them un-redacted.

[potiuk]

Current model absolutely does not allow any exposure of sensitive data via remote API - indepently on permissions. My proposal that I am going to bring to devlist if thewre will be no opposal in the security thread is to remove that export/import functionality for UI and leave a comment that you need to use local CLI.

I think it would be. very wrong to allow any remote access to sensitive data when there were voices how "lame" it is that we do it - previously we were doing exactly this the sensitive data was sent over to UI for those who had "connection write access" so if we allow that, we would be back to square one and we would be invalidating the CVE we just announced, so I would be surprised to see that happening.

[potiuk]

More details on the CVE: https://www.cvedetails.com/cve/CVE-2025-54831/

Apache Airflow 3 introduced a change to the handling of sensitive information in Connections. The intent was to restrict access to sensitive connection fields to Connection Editing Users, effectively applying a "write-only" model for sensitive values.

In Airflow 3.0.3, this model was unintentionally violated: sensitive connection information could be viewed by users with READ permissions through both the API and the UI. This behavior also bypassed the AIRFLOW__CORE__HIDE_SENSITIVE_VAR_CONN_FIELDS configuration option.

This issue does not affect Airflow 2.x, where exposing sensitive information to connection editors was the intended and documented behavior.

Unmasking values in export in UI, explicitly brings back the condition that triggered the CVE in the first place.

[potiuk]

Requesting change as the PR directly violates the security model we currently have in Airflow 3.

If we agree - in the security team - to change the model, we might want to re-evaluate this, but the current proposal that looks for consensus in the security team (and later in the devlist) is that the export functionality should be removed from the UI and users directed to the CLI.

[steveahnahn]

Thanks for the detailed security context @potiuk. I understand the concern and will be holding off on further changes until the security team and devlist reach consensus.

I'm happy to pivot this PR to implement that solution by removing the export button from the UI and adding appropriate messaging to guide users to export unmasked variables via CLI.

[potiuk]

Started discussion at the devlist https://lists.apache.org/thread/c79668yh42m5g7f7xck3oh6vft0z2kb6