Is the /status endpoint built-in? How to restrict it? Any other endpoints like this to be aware of?

[#1]

A security firm did an audit of our REST APIs. They found an endpoint that is exposing unnecessary and potentially harmful information. Anonymous users (i.e. a request without any token) are able to access:

https://<our organization>.apigee.net/<app>/status

(where <app> is sort of a root path that many of our proxies share)

It returns a bunch of information, including real-time database performance.

I have a few questions:

1.Is the /status endpoint something that's built-in to Apigee? I could not find it as part of our proxies, products, developer apps, or code repos.

2.How can we restrict it so that it will return a 401 for anonymous users, or otherwise NOT reveal this database/config information?

3.Is there any way we could scan our entire organization for any other such endpoints which are returning information / potentially sensitive payloads to anonymous users?

Thanks.

[ceber]

How are your proxies defined? Do you have key validation or security on the preflows for proxies? I expect that "/status" is being passed back to your target and that's where the return response is coming from... what does tracing the proxy show when you hit that URL?

[#3]

Thanks for the reply; however, I can't answer your questions. As I said in the question, "I could not find it as part of our proxies, products, developer apps, or code repos." So how could I trace "the proxy" when I can't find it? I even searched through all the available sub-fields/columns for each of proxies, products, and developer apps for "status" and could not find anything. Hence, I think it's built-in to Apigee and not a proxy that my company added. This leaves the question: how do I get that endpoint to stop revealing information to anonymous users?

[ceber]

The path that ends with "status" wouldn't necessarily need to be defined in any proxy for a request to that to return data. E.g. if you had a proxy named "app" where the basepath was defined as "/app" .. a request to "/app/status" could be handled by the "app" proxy.

In the example you mention, is <app> something specific or are there multiple values that can go in there? Do you have a proxy with basepath "/<app>" or one with basepath "/"? How many proxies do you have defined that might be catching that request?

[#5]

Sorry; you're right. I see what you're saying now. I'm trying a trace on that <app> proxy now.

[anilsr]

@Aaron Shaver ,

Is the /status endpoint built-in ?

- No, It's not built-in end point in Apigee. Most Probably it's from your target server.

How to restrict it ?

- You will restrict it like any other API Proxy. I see a bigger issue here where one of the API Proxy / Resource is exposed to target server without any security policy.

Any other endpoints like this to be aware of ?

- Apigee Org doesn't come with any endpoints / target server on it's own. It's just a gateway.

Most probably, It's returning from your target server. Apigee Trace is the best place to start debugging. It should not be hard to find root cause of above scenario. I would suggest you below things to find out what's causing above issue.

• Identify the proxy using the URL
• Open Trace Tab
• Make a sample call
• See the source of API response

If you would like to handle Unknown resources in API Proxy, this article might help you do that. keep us posted.

[#7]

Thanks. I'm trying a trace on my <app> proxy now.

[#8]

I found a Python script that's being executed for the /status endpoint. A coworker of mine is saying, "Most likely Apigee [created it] - they created the proxy for us to access the new 2.1 version of BaaS."