Apigee makes a great API Gateway product. But, one thing that’s been surprising is that the security system is not Deny Access by Default. It’s a very forward thinking design, but it surprised many of us who assumed the common security practice of Default Deny was the starting point.
For an application to have access to an API, the application must first be approved to use an API Product. The piece that’s surprising is that if an API Product has no API Proxies or Resource Path restrictions applied to it, then it gives full access to all API Proxies.
Don’t do this. Always attach at least one API Proxy to your API Products.
Once you have an API Product setup with an API Proxy, you have restricted access to just that API Proxy’s endpoint. Which is a good step forward. But, it gives you access to the entire endpoint, with no filtering on the “known paths”.
Beware of not applying resource path restrictions. Without resource restrictions, everything going through your API Proxy’s endpoint is passed through.
For example, if an API Proxy has a base path of:
https://{org}-{env}.apigee.net/firstapiproxy
And, that API Proxy has “known paths” (eg. flows) of
- GET /cars
- GET /trucks
- GET /vans
Because there are no resource path restrictions, these urls will also work:
- https://{org}-{env}.apigee.net/firstapiproxy/garbledjunkpath
- https://{org}-{env}.apigee.net/firstapiproxy/internalhealthcheckaddress
To apply the Resource Path restrictions use the API Product interface:
Or, for even stricter security, create a DefaultNotFound Flow within your API Proxy. Like the Send404NotFoundResponse used in the oauth2/proxy example:
0 comments:
Post a Comment