No. The Airflow documentation says Airflow does not authenticate plugin FastAPI apps, and that authenticating them is the plugin author's responsibility. Plugin routes are mounted apart from the core API, so the core authentication does not cover them. Review every plugin that adds routes, and confirm it checks the user.
Where plugins come from
Airflow's plugins page describes two loading paths. You can drop files into the plugins folder under $AIRFLOW_HOME, or package a plugin and register it through a setuptools entry point under airflow.plugins. If the package is installed, Airflow loads the registered plugins automatically.
By default plugins are lazily loaded and never reloaded once loaded, except UI plugins. After a change, restart the webserver and scheduler. The page also notes that task execution forks by default, so changes used in tasks may need a worker or scheduler restart.
What a plugin can add is broad: external views, embedded React apps (marked experimental in the page), FastAPI apps and middleware, macros for DAG templates, operator links, timetables, listeners and custom deadline reference classes.
The authentication note
This is the part security reviewers should read twice. The documentation states that plugin FastAPI apps are not authenticated by Airflow. Because their routes are mounted separately from the core API, the core API's authentication dependencies do not apply to them. Unless the plugin authenticates its own routes, they can be reached by anonymous callers.
The page recommends attaching the user lookup at the application or router level, so routes added later are not left open. It also draws a line between authentication and authorization: the plugin must decide what each signed in user may do, including team scoping in multi team setups. The example app in the page is called a structural illustration, not a template to deploy as is. It also advises protecting all views against cross site request forgery, noting that exemptions exist but are not recommended.
Plugin review checklist
| Question | What to look for |
|---|---|
| Does it add routes? | Check authentication is applied at app or router level |
| Does it check permissions? | Authentication alone is not enough |
| Does it handle state changing requests? | CSRF protection on every view |
| Where does it come from? | Internal repository or a package you reviewed |
| Which loading path? | Folder files are easy to change quietly, so control write access to that folder |
| What does it need at install? | Review its dependencies as part of the same change |
A simple process
- Keep plugins in version control and deploy them through the same pipeline as DAGs.
- Make the plugins folder read only on running containers.
- Require a second reviewer for any plugin that adds a web route.
- Test with an unauthenticated request. If a route answers, fix it before deployment.
- Record plugin packages in your software inventory with their versions.
Where Safeguard fits
Safeguard's dependency scanning and SBOM generation can inventory the packages a plugin pulls in, and the policies and gates feature can stop a pull request that adds a vulnerable one. A free scan is the easiest way to see your current picture.
Quick check
Does the plugins folder need special protection?
Anyone who can write files there can add code that Airflow loads. Restrict write access and deploy through version control.
Is Airflow login enough to protect plugin routes?
Not automatically. The docs say plugin authors must authenticate their own routes.
Sources
Last reviewed: 19 October 2026.
