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 , and Architecture is in the background to support that Design. delivered and used what runs the API 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? , “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%)." TechRepublic reported 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 ( finds a median code time of 52 minutes a day per developer, with the main cause being ineffectively deployment of the teams). one study ●       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 for fixing it.” So, assigning security champions and responsible parties is a key component of security strategy. no one is responsible 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 model, which considers a Shift-Left concept. OWASP’s DevSecOps 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 section, though the setting can be made Private. That openness strategy has led to unintended data scraping issues in the as, in the not-too-distant past, someone scraped the private information of 200 million Venmo users. Payment activity and Privacy past few years 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.

API Architecture: Components and Best Practices

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

5 Reasons Traditional Security Tools Fall Short in Protecting APIs

100 Days of AI Day 1: From Newsletter to Podcast, Leveraging AI for Audio Transformation

10 Threats to an Open API Ecosystem

10 Indications That You Should Invest in Automation Via APIs

10 Best Practices for Securing Your API

The Noonification: Getting Your API Into Production (10/28/2022)

5 Reasons Traditional Security Tools Fall Short in Protecting APIs

100 Days of AI Day 1: From Newsletter to Podcast, Leveraging AI for Audio Transformation

10 Threats to an Open API Ecosystem

10 Indications That You Should Invest in Automation Via APIs

10 Best Practices for Securing Your API

The Noonification: Getting Your API Into Production (10/28/2022)

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps