I am obligated by contract to prevent enumeration of an API method's parameters but cannot achieve it.

When I send a blank request to the API server in a web browser, the server responds with the exact parameters that that API method requires. This makes an attacker's job much easier because they know exactly what data to send to that API method.

For example, if I enter https://www.example.com/api/jsonpostgw.aspx?m=MethodName into a web browser, I get back a response, similar to the following, containing the exact parameters used by that method:

{"initObj": {"Locale":
   {"LocaleLanguage":"","LocaleCountry":"","LocaleDevice":"","LocaleUserState":"PossibleValue1 || PossibleValue2"},
   ”Another Parameter":""”,"AnotherParameter”:”PossibleValue1 || PossibleValue2"},
   "username": "", "password": ""}

This information tells the attacker exactly what data to send to the API method making attacking it much easier.

What I need to do is prevent the server from responding with this information when a blank request is sent.

Of course, these parameters are always sent via POST, not GET like when I send the URL in the web browser. So, one work around is to prevent GET requests.

How can I prevent these responses from the server without relying on this work around?

  • Restricting GET requests will only affect discoverability of the API in the very simple use case of pasting URLs into a browser. Is that what your requirement is to prevent or are you required to prevent more? If so, what? Commented Dec 9, 2015 at 16:43
  • Your question is incomplete. What is jsonpostgw.aspx? Is that part of some framework you are using? If so, please include the name of the framework in your question. If not, then what is stopping you from changing the API respons so that it does not include parameter names? Commented Dec 9, 2015 at 16:45

3 Answers 3


You are going about security the wrong way!

Attempting to secure something by hiding information about it is called security by obscurity. It is considered bad practice and should not be used. The general philosophy is that it is hard to keep things like an API secret. A determined attacker will backwards engineer the client application, watch the network traffic, probe the server, etc... to discover the signature of an API.

Instead, implement an API that is secure even in the face of being publicly known. Rely on secrets (such as passwords and authentication keys) and other access control mechanisms to secure your API's security. OWASP is a good place to start reading about security.

  • I agree with you about securing the API. I know that users can get this information from their clients. The reason for this is not security through obscurity, but rather preventing enumeration by people who are not legitimate users. I do see your point of view, but this is a business requirement of my client which I have no say in. Their corporate security policy forbids APIs from allowing this sort of remote enumeration, and their platform can not go live while it is doing this.
    – user94044
    Commented Dec 9, 2015 at 16:03
  • @user94044 OK. I edited the question to try to make it more clear what you're asking for. I did more editing than I'm typically comfortable with so please check the question and re-edit if you feel appropriate. Commented Dec 9, 2015 at 16:40

Per the the CERT Oracle Coding Standard for Java, "reflection with the permissions of trusted code is one of the "ultimate" security breaches in Java. Never permit untrusted code to invoke any API that eventually uses reflection to accomplish its actions." MSC53-J. Carefully design interfaces before releasing them

Another useful resource on securing APIs would be Rule 10. Thread APIs (THI)


Fundamentally, Neil has a great point, though I think specifically the issue you need to focus on is:

It appears API endpoint is open and implements no authentication system or access controls at any layer.

The OWASP's Guide to Access Control & Guide to Authentication covers this in great detail.

To address the business requirement you specified using a defense-in-depth approach, you should (at least) implement the following layers of security)

[Network Layer] -- Network ACLs (at Firewall / Router) specifying the IP addresses
   or network segments that are allowed to access the systems hosting your API

[Application Layer] -- Authentication Logic - before any request is processed by
   your API, you should require that the submitter present an authentication key
   or token to validate that they have been trusted to interact with your API.  
   Failure of a client to present a valid key should cause your API to return 
   an HTTP Status Code 404.

[Application Layer] -- Business Logic - After completing your authentication
  logic you should inspect the parameters and return an error code 5XX 
  along with a message indicating that parameters are missing.

Note: From your description, it appears that you are using IIS to host your API endpoints. I'm not that familiar with the platform, but what you are describing sounds to me like a default behavior that is being executed because either:

  1. You have not overridden the default .Net response logic with custom code that implements something like the above suggestions.
  2. You have not configured the default settings of the IIS web server to avoid this parameter enumeration.

Although addressing either of the above should satisfy your requirements, I'd suggest #1 to give you more control over exactly the behavior that is executed and a more robust security system. Here are a few additional reference links that may assist you in either approach on the IIS platform:

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .