Tag Archives: risk profile

I’m going to be speaking about API security at next week’s 2012 RSA conference. I gave this talk the provocative title Hacking’s Gilded Age—How APIs Will Increase Risk and Chaos. It’s scheduled for Friday, March 2, 2012 at 10:10am in room 302.

Here’s the long form of the abstract, which gives a little more detail of what I’m going to cover in the talk than the short abstract that’s online:

This session will explore why APIs (which are largely RESTful services) are fundamentally different than conventional web sites, despite the fact that they share common elements such as the HTTP protocol. Web sites abstract back end applications behind a veneer of HTML that should—if it well designed—constrain capability and thus limit an organization’s security exposure. APIs in contrast are a more explicit interface leading directly into applications. These often self-document their intent, and thus provide a hacker with important clues that may reveal potential attack vectors—from penetration to denial-of-service. Because of this, APIs require a much more sophisticated model for access control, confidentiality around parameters, integrity of transactions, attack detection, throttling, and auditing.

But aside from the technological differences, there are cultural differences in the web development community that considerably increase the risk profile of using APIs. Many API developers have a background in web site development, and fail to understand why APIs demand a more rigorous security model that the web sites they were trained on. In a misguided attempt to promote agility, convenience is often chosen over precaution and rigor. The astonishingly rapid rise of RESTful services over SOAP, OAuth over SAML, API keys over certificates, and SSL (or nothing) over WS-Security is a testament to fast and informal prevailing over complex and standardized.

Nevertheless, it is certainly possible to build secure APIs, and this session will demonstrate specifically how you can spearhead a secure and scalable API strategy. For every bad practice, we will offer an alternative pattern that is simple-but-secure. We will explicitly show how the API community is dangerously extending some web paradigms, such as avoiding general use of SSL or not protecting security tokens, into the API world where the cost of failure is far greater. And finally, we will prescribe a series of directives that will steer developers away from the risky behaviors that are the norm on the conventional web.

I hope you can attend. And if you do, please come up after the talk and say hello.

See you next week in San Francisco.