Security for Public API

Not applicable

We are planning to expose an API on Apigee platform for a single page app (direct API calls from browser).Its a read only content for public consumption. Do we require security at all ? if not will throttling/spike arrest be sufficient ?

1 7 704
7 REPLIES 7

Not applicable

You may have some authentication in the app itself to authenticate the user as first step.

And then I think the public APIs should be at-least secured by API Keys per session basis instead of hard-coding them in JavaScript. That way you can track who exactly is calling your Public API.

Also as you rightly mentioned having Spike Arrest & Quota should be configured.

I agree that traffic management is a good idea, and using API keys to identify the app makes sense to me. How frequently you generate a new key is up to you, but I would set up some sort of automated rotation capability.

I think I'd also include a comment in the source of my app that directed interested developers to my dev portal, and encourage them to sign up for their own API key to use with the API. If you make it easy enough for a developer to get a key, hopefully you wouldn't need to worry about people re-using your SPA key (but some will, which is one reason I'd rotate them).

+1 to both @Carlos Eberhardt's and @Swapnil Raverkar's suggestions. I’m going to assume it isn’t user-oriented data, for the moment, and I’ll second the suggestion that an API key may be the right approach. A single-page-app lives in a view-source world, making it difficult to protect any "secrets" without some server-side help. That API key offers a mechanism to identify the client making the request, and even though that key is discoverable, it can be cycled at any time. If nothing else, this would be an architectural posturing that signals an intent. You could argue that’s akin to a "Protected by Bay Security" or "Beware of dog" sign, but it does matter. Plus, consumer use cases tend to grow over time, and you'll already have a built in mechanism to identify clients.

@Carlos Eberhardt's source code comment directing to a developer portal is clever and worth considering.

Not applicable

I understood from the question that this is data for public consumption. In these cases, it is often the goal to maximize consumption, so advertising the data, not protecting it, is the goal. If that is the case, I would not enforce keys. I would make sure that each URL in the API supports both JSON and HTML responses that contain equivalent information, and wait for the Google search bot to come calling (reference the API in your main website to get Google's attention). Make sure the HTML has links in it so Google will crawl the whole API. [It's a good idea to put the same links in the JSON too, but that is another topic.] The HTML format will probably never be seen directly by humans because your SPA is rendering the UI, but having Google index your API will be very cool. Spike arrest may be important to you to handle load, and (if you can figure out how) having optional keys to identify some 'special' callers might also be useful.

I think you're suggesting that API keys could be useful, but that enforcing them or restricting them is not something worth pursuing at the beginning. Is that correct?

It's pretty easy to use apikey for identification (not authentication, or any sort of security). Just tracking. And in Edge it's easy to support both completely open and "identified" access .. like so...

    <PreFlow name="PreFlow">
        <Request>
            <Step>
                <Condition>request.queryparam.apikey != null</Condition>
                <FaultRules/>
                <Name>VerifyAPIKey</Name>
            </Step>
...

If a key is supplied I validate it, and analytics captures all that juicy good info. If no key, no big deal, everything still works.

Not applicable

Interesting comments by Martin .The question here is should API key(or any security means) be a requirement or should it be a optional ? I liked Carlo's idea of "apikey " as an identifier and not a authenticator.

I am still leaning towards having a rotation of APIKeys simply because this is just one of the services ,from a group of other services (B2B,B2C) thats going to be exposed on Apigee Edge.If this service is compromised ,it may openup other services(or API proxies within the Org) for attacks.

Note: I feel I am getting paranoid with security 😛 ....