Security frameworks help IT Architects know what they don't know

Application programming interfaces (APIs) can be an IT Architect's best friend. Application programming interfaces quickly interconnect products and services, enable the effective reuse of resources, and allow stable abstractions so that people don't need to know the internal workings of everything they're integrating. However, communication among multiple digital touchpoints creates multiple channels of vulnerability, which is why API security has to be at the forefront of IT Architects' minds.

Indeed, the open-access afforded by APIs has untold benefits but also introduces new levels—and layers—of risk. In addition, the API attack surface is rapidly growing: In 2014, Akamai researchers conducted an informal analysis of statistics to determine how much traffic was coming from API traffic as opposed to HTML traffic. At the time, the researchers were surprised to find that API traffic accounted for 47% of all data traffic the organization saw. That percentage has only grown, according to the Akamai State of the Internet/Security: Retail Attacks and API Traffic report. "We recently decided it was time to look at API traffic again, and the results were once again surprising," states the report. "The traffic classified as APIs currently accounts for 83% of all hits, while HTML traffic has fallen to just 17%."

[ Learn about the Zero-Trust approach to designing security architectures. ]

However, the rise in APIs and API traffic does not necessarily come with an increase in API security.

"Everybody writes or uses APIs, but not everybody is (or wants to be) a security expert," said Mike Bursell, Chief Security Architect for Red Hat.

This is where security frameworks come in, Bursell added. "Frameworks allow you to find out what you don't know so that you can find someone to help you who does."

And, what you don't know can certainly hurt you and your customers. To help IT Architects leverage the benefits of APIs without expanding the organization's threat landscape, frameworks like Open Web Application Security Project's (OWASP) list of the Top 10 unique vulnerabilities of APIs can go a long way toward ensuring that APIs created and/or used by organizations are properly secured.

"One of the strengths of having frameworks is that we're not having to reinvent the wheel each time," said Bursell. "Let's learn from others and build better each time."

OWASP's list of the top 10 API vulnerabilities—and recommendations for overcoming them—are:

Broken object-level authorization: APIs tend to expose endpoints that handle object identifiers, which creates a wide attack surface. To address this, consider object-level authorization checks in every function that accesses a data source using an input from the user.

Broken user authentication: Authentication mechanisms are often implemented incorrectly, allowing attackers to compromise authentication tokens or exploit implementation flaws. Organizations should take care to put systems in place to accurately identify the client/user.

Excessive data exposure: Avoid exposing all object properties without considering their individual sensitivity.

Lack of resources and rate-limiting: To avoid impacting API server performance, developers should impose restrictions on the size and number of resources requested by the client/user.

Broken function-level authorization: Attackers can gain access to other users' resources and administrative functions when the separation of admin and regular functions is unclear.

Mass assignment: Be sure to bind client-provided data (such as JSON data) to data models with proper properties filtering based on a whitelist, preventing attackers from modifying object properties they are not supposed to.

Security misconfiguration: Avoid security misconfiguration errors such as insecure default configurations, incomplete or ad-hoc configurations, open cloud storage, misconfigured HTTP headers, unnecessary HTTP methods, permissive cross-origin resource sharing (CORS), and verbose error messages containing sensitive information.

Injection: Injection flaws—such as SQL, NoSQL, and command injection—occur when untrusted data is sent to an interpreter as part of a command or query.

Improper assets management: APIs tend to expose more endpoints than traditional web applications, making it even more important to have proper and updated documentation.

Insufficient logging and monitoring: OWASP notes that most breach studies report that it takes more than 200 days to detect a breach and that external parties typically discover the breaches rather than internal processes or monitoring. Organizations must implement sufficient logging and monitoring capabilities to prevent attackers from maintaining persistence.

The OWASP list will help IT Architects balance API function and security, but it's not the only resource available. IT Architects can seek out guidance from government organizations and specific checklists from an organization's technology vendors, as well as look to industry thought leaders for advice and best practices.

Conclusion

Not using APIs is not an option—not if organizations want to remain competitive. By acknowledging and addressing API vulnerabilities and using frameworks that build on best practices and lessons learned, IT Architects can work across the business to ensure that the technology's full value can be realized.