Evolution of the API Security Top 10
Erez Yalon, Checkmarx
When first published in late 2019, the OWASP API Security Top 10 was well received and widely adopted by the industry, becoming a reference document on API Security. By that time, APIs were already powering an ever-increasing number of software solutions without undergoing rigorous security testing that would help make them secure from attacks. By 2022 APIs were expected to become the most-frequent attack vector.
Guess what? It’s 2022!
Technology moves forward, and we are moving forward with it. Prepare for the new 2022 edition of the OWASP API Security Top 10!
We’ll take this opportunity to discuss why an API-specific list of the ten most critical security risks was needed and why it still makes sense. Data from ongoing research on the state of API security will be presented and open for discussion.
The OWASP API Security Top 10 was created to address API-specific risks, providing value to software developers and security assessors by undergoing the potential risks in insecure APIs and illustrating how these risks may be mitigated.
We invite every security practitioner to contribute to the OWASP API Security project, attend this talk, and participate in the discussion.
Automated APIs for Scaling Enterprises: How to Set Standards and Create Smooth API Implementations
Jeremy Glassenberg, Docusign
API standards and schemas have helped to automate much of API design, implementation, and maintenance — and not a moment too soon. As many tech companies experienced growth spurts in recent years, they encountered the challenges of having multiple teams launching new APIs. Consequently, they learned that their ways to create well-designed APIs wouldn’t work so easily when multiple teams have to create them.
Beyond well-designed APIs, is the need for consistency across APIs, coordinated across teams. How can this be managed – ensuring consistency while allowing individual teams the autonomy to plan their APIs?
Thanks to new API tooling, growing companies can establish a scalable system for designing, implementing, and launching consistent APIs across multiple teams. We’ll share best practices and solutions from experiences among growing software companies in this phase to understand how to be effective working across Product, Infrastructure, and Engineering teams to do so.
Developing API-First Multi-Protocol Services with Cadl
Brian Terlson, Microsoft
This talk is an introduction to Cadl, a new, next-generation programming language for defining APIs. Developers use its simple core semantics and rich templating and extension mechanisms to represent APIs in any protocol and encapsulate common API shapes and patterns into reusable components. This description can be compiled to a variety of assets including standard OpenAPI3 or gRPC service descriptions, client or service code, documentation, database migrations, and other assets.
This talk will walk through building a web service which demonstrates many of these capabilities. Using the Cadl language combined with modern IDE features like code completions and refactorings, and leveraging the OpenAPI emitter from Cadl’s standard library, we will develop a service description that can plug in to any OpenAPI3 code generation pipeline while requiring an order of magnitude less code. We will show how we to abstract out common parts of the service description to make subsequent API development and review faster and ensure consistency among all endpoints. We will demonstrate how to extend the API description to represent the same service in gRPC and represent other aspects of the service’s implementation like the database ORM layer. Finally, we will cover Cadl’s TypeScript-based extensibility model and library story which developers can use to build and share API patterns, custom language extensions, linters, emitters, and more.
JSON Schema in Production – You Can Use It Today
Ben Hutton, Postman/JSON Schema
Come hear the about the journey of organizations that use JSON Schema in production today, and learn about how JSON Schema continues to deliver value.
“Isn’t JSON Schema still a draft? Is it ready to be used in production?”
We see these sort of questions come up every now and then.
The truth is, many developers use JSON Schema without even realizing they are using JSON Schema.
Have you ever wondered how autocomplete and intelisense for configuration files in your IDE or code editor works?
Seen something “similar” to JSON Schema for generating forms or TypeScript types inside API definition files?
That would be JSON Schema.
In a series of case study like interviews, I’ve chatted with several individuals at companies and organizations of various sizes about challenges that led them to JSON Schema.
Specs are Important, Trust is Vital
Shai Sachs, Wayfair
What is missing in an API spec? How can we ensure that our APIs are not only used – they are enjoyed?
In this talk we’ll argue that trust between producers and consumers is ultimately the most important element in the success of an API. We’ll take a look at how API specs can create trust – and also where they fall short. We’ll learn how we can create trust that outlives any one spec document.
It’s no question that specs are important artifacts in API development. Alongside service-level agreements (SLAs), they’re crucial to communicating what an API does – or at least, what it’s supposed to do. We often say that specs and SLAs are our “contracts”, drawing inspiration from the legal world.
But contracts aren’t enough to ensure good behavior in the legal world, and specs aren’t enough to ensure that APIs do what we want! To build APIs that consumers really enjoy using, we need to build trust.
