Module
Module 4 of 6Lesson 2 of 2~14 min

The API flaws a PM should know how to spot

Lesson 2 of the module "Authentication, permissions and security" in the course "Design and test an API integration as a PM".

Take this lesson: your first course is freeSee the full syllabus

Lesson objective

By the end of this lesson, you will be able to spot in an integration the most frequent risks of the OWASP API Security Top 10 (access to someone else's object, excess data exposed, unrestricted consumption, blind trust in a third-party API) and write the matching security criteria in the spec.

Where it fits

Authentication, permissions and security

Who may call the API, to do what, and how do you avoid the most common flaws?

Lessons in this module

  1. API keys, tokens and OAuth 2.0, choosing and specifying
  2. The API flaws a PM should know how to spot (this lesson)

What you will learn in the course

This lesson is part of the course Design and test an API integration as a PM

  • Read a REST API's documentation (resources, endpoints, methods, parameters, JSON bodies, OpenAPI description) and extract what the integration needs.
  • Send, save and test requests in Postman or Bruno (collection, environments, variables, assertions) to check an API's real behavior.
  • Interpret status codes and error responses, and decide the product behavior (fix, retry, alert, inform the user).
  • Choose and specify the authentication method (API key, token, OAuth 2.0), the minimal permissions and the rules for managing secrets.
  • Specify pagination, rate-limit handling, webhooks and idempotency for an integration that withstands volumes, outages and duplicates.
  • Plan environments (sandbox, production), versions, breaking changes and deprecations in the spec and the test plan.
  • Write a complete integration spec, with a collection of tested requests, ready to be estimated by the team.

Related courses