While API Architecture and API Design are different, when it comes to securing them, both need to be kept in focus. In a short and simplified way, Design is how the API service will be delivered and used, and Architecture is what runs the API in the background to support that Design.

Because they’re so closely related and both require close attention to details for secure implementation, I’ll include both architecture and design in talking about securing APIs, at times (perhaps to the reader’s chagrin) using them interchangeably.

Why Pay Attention to API Architecture and Design?

TechRepublic reported, “As workloads and applications proliferate, 23% of attacks now compromise API security. The top types of API attacks include data exposure (encountered by 42% of respondents in the past year), SQL and API injection attacks (37% and 34%, respectively), and distributed  denial-of-service attacks (33%)."

Criminals know APIs are abundant and vulnerable. Whatever the cause of the vulnerabilities - lack of resources to upgrade, lack of documentation, inadequate personnel expertise - what matters is that these marvels of modern technology that are a boon for business may also be the advantage needed by threat actors to compromise business and undermine the advantages.

On the positive side, customers want to have a clean, clear, reliable, and trustworthy experience with a business, and API design can provide exactly that.

By Business, For Business

The main goal of API architecture is to answer, “What are we doing?” by answering questions such as: Who are the customers being served? What’s the goal of using these APIs? What industry is using the service? Aligning technology with business strategy will help keep all eyes on the main thing, which is working together to help customers achieve their goals.

PPT Considerations

Using the tried-and-true People, Processes, and Technology (PPT) triad, let’s take a look at approaches to architecture and design.

People

Because so many People in different departments are involved in API development, here are some (but not all) components to consider for personnel security training:

●       Developers should learn and apply secure code (I keep meeting developers who have never heard of OWASP).

●       Managers need to provide time for their teams to secure products (one study finds a median code time of 52 minutes a day per developer, with the main cause being ineffectively deployment of the teams).

●       Site Reliability Engineers should find and fix vulns in infrastructure.

●       Product Managers need to add security requirements to products.

●       Security personnel must focus on helping everyone mentioned above (and more!) be successful.

While there are multiple people involved, “…making it everyone’s problem means that no one is responsible for fixing it.” So, assigning security champions and responsible parties is a key component of security strategy.

Processes

Perhaps the greatest leverage in Processes is the SDL (or SDLC – depending on whether it’s “lifecycle” or “life cycle”). When written well, the SDL contains numerous processes, procedures, personnel, and other resources, including diagrams, notes, and references to repos. Obviously, a complete reference for all of these, including complete API documentation, would require too much administrative work to maintain.

But, leveraging a well-designed SDL will go a great distance in properly designing one’s AppSec program, including API architectural needs.

One useful diagram to include is something similar to OWASP’s DevSecOps model, which considers a Shift-Left concept.

Technology

Is your API service a Monolith or Microservice? Which architectural model - REST, GraphQL, gRPC, or SOAP (even though SOAP is older and considered legacy, it still needs to be secured!) – best fits the design?

API architecture needs to take Interoperability into account. Will it work with other technologies used by the business, customers, and partners? Can it be tested and maintained adequately?

Other Considerations

Privacy and Regulations

GDPR, CPRA, HIPAA, TX-RAMP - the list goes on, and it's getting longer every congressional and parliamentary session. What data (health, top secret, student) is being transferred? Are payments being made that require PCI-DSS-level protections? Is data being transferred over national borders?

These answers may weigh heavily on – or even determine - the choice of architecture used for the API implementation.

Security

Under the aspect of technical security, here are a few elements to keep in mind - 3 top threats for testing and which need constant vigilance.

Reduce Data Exposure

Minimize what is revealed publicly about the architecture and design. Reveal as little as possible in API calls, F12, packet capture, etc. so that threat actors don't have any more to go on than what's necessary.

Don’t rely on client-side protections and filters, testing to ensure only the right kind of information is displayed in the browser or API calls.

Broken Object Level Authorization

To avoid the ability to access objects by manipulating or enumerating IDs, check access for each and every input and use random and unpredictable unique record identifiers.

Broken User Authentication

Knowing all the authentication flows, using MFA, and implementing throttling, lockouts, and password checks are ways to mitigate attacks such as credential stuffing and using stolen auth tokens to take over accounts.

A Cautionary Tale

In Venmo, transactions are public by design and by default, a factor noted in the company’s Payment activity and Privacy section, though the setting can be made Private. That openness strategy has led to unintended data scraping issues in the past few years as, in the not-too-distant past, someone scraped the private information of 200 million Venmo users.

Ensure that your APIs act as intended, including what data should be displayed according to business needs. Not only should one align API design with business policies, but organizations must be aware of what can be done with what's displayed.

Maturing a security program goes beyond following a checklist by including a look ahead at the potential repercussions (e.g., what can criminals do with what an API shows them?) and planning a response accordingly, which then turns back to potential architecture changes if the risk of the design is greater than the ROI.

APIs are integral to business, making API architecture, design, and security integral to the business. As someone has said, “Do the next thing next, and the next thing will follow.” Check your roadmap, and do the next thing.