Is the API meant to be shared between teams or is it essentially just for the team that deploys it?

If the API is meant for other teams, they need some documentation and that must be delivered. Swagger that's available in network is reasonable. Also, if your SRE is expecting a threat on the internal network, it's worth looking at everything else that could be done on the internal network. Like if someone can see the code for the API just by being on the internal network, removing swagger is pointless.

A lot of the problems with enabling swagger go away if you host it separate from your API. Since it's not co-located with the API, it's effectively just another client on the network (from the api perspective) and DDOS is pointless. So maybe that's enough to satisfy the SRE?

But if swagger is just meant for the internal teams as maybe documentation for new folk, etc basically people who can already access the code. Not much gain in hosting it, so might as well turn it off.

I'm also a little confused on how a static site that displays no user generated content can be exploited via script injection? It's clear someone can pwn you if they can control your swagger file, but publishing the swagger file should already be secured. Maybe the swagger UI's I'm used are more basic than the exploitable ones?

jmathew‭ By API I mean the list of exposed endpoints by a Web API (in my case it is an ASP.NET Core API). The goal is the following:

• provide documentation for other teams
• allow easier testing for our team on non-DEV environments

We already have Swagger enabled on non-prod environments. so I am not sure if a separation is still required.

Separating it is sort of a paranoid safety measure in case there's any way to exploit the Swagger middleware (AFAIK there is none). And perhaps Kestrel*, though touted as production ready, may not be able to serve actual API requests while receiving millions of requests (DDOS) for large static assets (swagger UI js and html files, images, etc). Especially compared to a CDN. But I haven't actually tested that at all. If you were interested in doing that you could run something like Seige (https://linux.die.net/man/1/siege) or K6 (https://k6.io) on a sufficiently resourced machine and see what happens. I'd be interested in the results as well if you do.

But really all of this is very unlikely inside the network anyway. In my opinion, unless the SRE can point to any direct concerns, the pros of swagger availability win by default.

*If you're using Kestrel. I suppose there's IIS and a few other options as well...