search

NREL / api-umbrella

Open source API management platform
MIT License
2.03k stars 325 forks source link

Validate frontend prefixes #239

Open brylie opened 8 years ago

brylie commented 8 years ago

API Umbrella does not seem to validate frontend prefixes. This has been observed in two ways:

It may also be possible to override internal routes, such as /admin.

Feature request

Add validation to frontend prefixes, such as:

GUI commented 8 years ago

Good points. Semi-related to the prefix collision issue is: https://github.com/18F/api.data.gov/issues/186

Regarding restricted prefixes, in our environment, we've sort of solved that in the reverse fashion by only white-listing where admins can operate with the Admin Scopes & Admin Groups permissions. So, for example, we limit teams so they can only operate under api.example.com/foo/*. But I also think preventing some restricted paths is probably a good idea too.

Although, I believe /admin/ should always be routed ahead of API matches, so I don't think it's possible to override that, but we need to double check (but you won't currently get any errors, it just won't route). We also need to be careful if we place any restrictions on the root prefix of /, since actually do need to allow that prefix for secondary domains (we have a couple of these in our case, where we essentially have API-only domains CNAMEd to API Umbrella without a website or admin, and just APIs at the root route).

Thanks for reporting this!

KrishnaPG commented 8 years ago

+1 for the 'preventing restricted paths`.

A validation criteria (regEx or similar) that works across the Admin Scopes for rejections (of say, inappropriate words, well-known bad routes etc.) should resolve this situation.

For example, the rejection regExs run before the white-listings of Admin-scopes and system could ship with couple of in-built regExs, such as:

This way, it protects the in-built paths required by the system, as well as providing the Admins more control over the route specifications.