When most people think of Santa Clara, they immediately think of the San Francisco 49ers, as that is where their stadium sits. They might also think of California's Great America, an amusement park that has been keeping folks entertained since the 1970s. Given how many tech companies have headquarters there, including Advanced Micro Devices, Intel, and Nvidia, many people think of it as an important part of Silicon Valley. For a few thousand who gathered there in late October, it will always be associated with API and AI advancements, thanks to API World 2023. 

This year's event was colocated with AI Dev World, bringing together practitioners from both, highly related realms. It makes sense as the largest innovations in the artificial intelligence and large learning model, LLM, space over the last few years have involved API integrations to services like OpenAI's ChatGPT and IBM Watson. It seems that developing any AI means also means building and maintaining an API as well. 

There were over 70 speakers throughout the 3-day event. That is far too much to cover in depth here in this article, but here are some of the highlights.

The future of AI is unpredictable

In their opening keynote session, "Navigating Invention, Innovation & Disruption in the Age of AI," Khurram Latif, from Deloitte Consulting and Justin Hiza and Michaël Chaize of Shutterstock laid out some of the more exciting ways they are collaborating on products powered by AI and shared some thoughts about the future of the technology.

Shutterstock is a stock content company selling premade images, videos, audio, and many other types of media. They have been using AI for years, primarily to classify and suggest related content on their site automatically. Generative AI used for personalizing content is a new effort for them, though, and that is why they partnered with Deloitte.

They demonstrated some examples, including their "Magic Brush" feature that allows users to customize existing content based on provided prompts. For example, if someone needs to wear an "on-brand color" hat, you simply tell the AI what you want, and it will do the placement, lighting correction, and all the other touch-ups in seconds.  The other was a custom text creator that derives a theme from a given image, customizing the requested text to match the image's theme perfectly. 

The team shared some of the more significant takeaways they learned while embarking on many AI projects together.  One of the most prominent lessons is we are entering a world without all the answers. They concluded it is basically impossible to guess what will work and what will not with AI even a year out.  If you overdesign something early, you will spend a lot of time trying to make AI do something it might not be capable of.

What does work is prototyping fast and getting feedback as rapidly as they can.  Starting with the customer goals and objectives, they empowered their engineering to deliver proof of concepts on any idea they thought moved towards those ends; ultimately, the customer is the one who judges if an AI innovation is valuable.

API World participants had the pleasure of seeing three different talks from Isabelle Mauny, Field CTO and co-founder at 42Crunch, that build upon one another.  In all of these sessions, she stressed the importance of API security and how we can use the recently updated OWASP API Top 10.

In her talk on the first day of the event, "Common API Security Pitfalls: Learning from Others' Mistakes," she walked us through several security incidents involving APIs. One case involved a microbrewery whose API allowed hackers to print thousands of free beer coupons. Another case involved a university's physical access control system that did not implement any authorization, meaning anyone with an account could gain admin rights. She summed up the main problem throughout all her examples was that API security was an afterthought. While starting our security work with the general OWASP Top 10 is good, we need to focus on the issues presented by the OWASP API Top 10 earlier in the process, at the design phase. 

Later, she dug into the larger cultural issues of API security. In her session "Why So Many API Security Solutions Have Failed to Deliver," Isabelle said that one of the biggest concerns is that most organizations have no idea how many APIs they manage. This stems from a lack of governance, a lack of training, and a tendency just to try to solve problems with tech tools. Good governance means building and communicating documentation on how to build APIs properly, report they exist, and secure them.

Securing your API is not your app's concern

The recommendation to address API security by leveraging the OWASP API Top 10 came up again in the session "Research Revelations: Emerging API Threats & How to Mitigate Them," from Patrick Sullivan, CTO of Security Strategy at Akamai. He stressed that traditional application security, which is what OWASP traditionally focused on, relied on WAF rules and gateways. But API threats are different. APIs can be used to scrape data, help attackers map a network, and make denial-of-service attacks easier to execute. 

Another major difference in security approaches is that while application security is something taken care of by the application, the app assumes no duty to secure the API. He said the most common thing he hears when confronting someone about an API vulnerability is, "I thought the app would take care of that." This is especially true when it comes to authorization. While traditional apps bake in logic, allowing a request to succeed only if certain conditions are met, most APIs allow anyone who can authenticate to make almost any call. It is up to the developer to handle this aspect of security via the code. 

Don't just follow the happy testing path

In his session "Why You Should Hack Your Own APIs," Dan Barahona, Founder of APIsec, said one of the biggest issues with API security is a lack of testing. APIs are often tested to ensure they do what you want them to do, but all too often, Dan says, we don't test if it does what it's not designed to do. We tend to follow a happy path when we need to instead think like an attacker and see what unexpected behavior we can force. 

He talked through several recent examples of API security gone wrong, mostly from logic flaws associated with authorization. The companies he mentioned included Coinbase, where a researcher was paid $250K for finding a flaw that could have ended the company; Duolingo, where guessing user IDs led to 2.6 Million users' emails and names being stolen; and Peleton, where an authorization flaw caused a leak of over 4 Million users' data.

Our job in API security should be to find the flaws before they get into the wild. We heard that starting with the OWASP API Top 10 is good, but he said more consistent and automated testing of unintended uses is required. He concluded his talk by quickly laying out his own best practices top 10 that they use in the free courses at APISEC University:

1. Start with Governance.
2. Know your API ecosystem.
3. Get Security and Development teams talking.
4. API Documentation is non-negotiable
5. Train API developers and owners on API security
6. Centralize API management 
7. Don't trust anything; validate everything.
8. Don't rely on UIs for security
9. Authentication is NOT authorization. Authorization must happen in the logic.
10. Automate pre-production testing whenever possible. 

The need for an API security purple team

An application is like an octopus. This is how Jeremy Ventura, Director of Security Strategy & Field CISO at ThreatX, began his session "Red + Blue = Purple: Strategies around API Security." Like an octopus, there is a central body and head which powers the application. APIs are like each outstretched arm that allows the octopus to move and interact with the world.

The traditional 'blue team' in security is focused on defending that central app, not the arms. Red teams are increasingly focused on getting in through any route they can. As API calls are now responsible for over 80% of web traffic, it is clear this is the new battlefront. We need to meet in the middle and shift the focus to securing and finding weaknesses in our APIs.

Jeremy said one of the largest issues is that most organizations do not know how many APIs they manage. This leads to a world of "zombie APIs" that should have been decommissioned, are unpatched, and still allow calls to be made. He said in an average engagement with a client, they find over 8x the number of APIs they first thought they had.

Aside from the OWASP API top 10, Jeremy said rate limiting and logging need to be addressed for most APIs. He said it is not enough to keep logs; you must actively act on any suspicious activity. The real way we can address these issues is to work together and set policies, train people, and use better testing tools earlier in the development process.  While admitting tech is important, he reminded us always to put people first when solving security concerns. 

Good security starts with knowing what you have

Throughout the event, in any session about API or AI security, almost every speaker mentioned the importance of understanding your assets as the first major step on your security journey. After all, you can't defend it if you don't know it is there. This is something I brought up as well in my session "Do you know where your secrets are? Exploring the problem of secret sprawl and secret management maturity" based on the Secret Management Maturity Model from GtiGuardian. In part of the talk, we walked through how mature organizations not only know where their secrets are, but they can audit and monitor their creation and use through a secret management service such as Hashicorps' Vault Enterprise or Doppler. 

It is also important to know what secrets you have in code and other places where they should not be in plaintext. This is where automated secrets scanning comes in. For example, when connecting a repository to the GitGuardian Secret Detection platform, it will perform a historical scan, letting you know where those secrets exist in your git history. From there it will actively monitor for any new secrets entering the perimeter, alerting you to their whereabouts. 

In secrets management, API security, and AI security, bolting on security after the fact is not an option. We need to address the vulnerabilities enumerated in the OWASP API Top 10 earlier in the development lifecycle and stop treating every issue as one that can be solved by tech alone. We also need good governance that creates good processes that people are trained on. We have a long way to go with securing our code and our APIs, but together. By learning from one another, we can find the best path to protect our apps and our customers.

*** This is a Security Bloggers Network syndicated blog from GitGuardian Blog - Automated Secrets Detection authored by Dwayne McDaniel. Read the original post at: https://blog.gitguardian.com/api-world-2023/