Attack vector

As explained in Secure APIs

An attack vector is a path, method, or weakness through which an attacker can compromise or misuse a system or API.

An attack vector is a path, method, or weakness that an attacker can use to compromise or misuse a system or API. In API security, every exposed input, component, configuration choice, and data flow can create such a path. section 1.1 section 1.4

Treating an API as a gateway into data and functionality makes attack vectors a design and operations concern, not only an implementation problem. Successful exploitation can cause unauthorized access, data leaks, service outages, privacy violations, financial penalties, and reputational damage. section 1.0 section 1.8

Common API attack vectors include:

• URL query and path parameters, request headers, and request payloads that accept unconstrained or malicious input. section 1.4 section 1.8
• Schema configuration and implementation choices that enable data corruption or mass-assignment attacks. section 1.4
• Internal and external service calls, network configuration, dependencies, databases, and other infrastructure components. section 1.1 section 2.2.1

Pagination and avatar-upload examples

A product endpoint such as GET /products?filter=' OR 1=1;-- may turn an unconstrained filter into SQL injection, potentially exposing data or bypassing object-level authorization. A request for 100 million items per page can overload the database and take the site down. Similarly, POST /user/avatar accepting a URL can enable SSRF: an attacker may make internal requests to an admin service, access sensitive data, scan private networks, or leak tokens. section 1.4 section 1.1 section 2.2.1

Figure 1.2 To secure our APIs, first, we identify attack vectors, such as the API input parameters. Then, we model the possible threats. Finally, we harden our API by applying measures that prevent or mitigate those attacks.

Use the attack-vector workflow: identify exposed inputs and components, model possible threats, then harden the API with preventive or mitigating controls. section 1.1

How Secure APIs covers it

How deep it goes

Defines attack vectors, demonstrates injection and SSRF consequences, and outlines identification, threat modeling, hardening, testing, and monitoring.

Examples

Uses pagination filters, oversized page requests, avatar URLs, internal service calls, private-network scans, and token leakage.

What it assumes

Assumes familiarity with APIs, endpoints, requests, and services while teaching security risks through concrete API interactions.

What you can do after

Diagnose/debug with it by mapping inputs and data flows, modeling threats, constraining requests, testing continuously, and monitoring behavior.

How it connects

Connects attack vectors with API security, threat modeling, SSRF, SQL injection, BOLA, network segmentation, and data flow diagrams.

liveBookmanning.com

Read Secure APIs on liveBook Get the book at manning.com

Related concepts

• user input leakageincludes · User input leakage is the unintended exposure of sensitive information supplied by a user to an AI system or its downstream components.
• training data extractionincludes · Training data extraction is an attack that elicits information from a trained model that was present in its training data.
• phishingincludes · Phishing is a social-engineering attack that uses deceptive communications or content to impersonate a trusted source and induce disclosure of information or another unsafe action.
• threat modeladdressed by · A threat model is a structured analysis or representation of a system’s relevant threats, adversaries, assets, attack paths, assumptions, and possible mitigations.

This explainer was generated by Manning's knowledge graph from the text of Secure APIs. The section links point to the parts of the book it draws on.