RedTeam Nexus Labs
Module 01 · Lesson 03 // Web Architecture

APIs

Web Architecture · Web Security

Freereading · 10 min
On this page
LESSON

Overview

Behind most modern web and mobile apps are APIs — the backend endpoints that the frontend calls to fetch and change data. APIs are where much of an application's real attack surface lives. This lesson introduces APIs from a security perspective.

Learning objectives

  • Define an API in the web context.
  • Explain how frontends consume APIs.
  • Recognize why APIs are a major attack surface.

Core concept

An API (Application Programming Interface) is a set of backend endpoints that accept requests and return data, typically as JSON, over HTTP(S). Instead of the server rendering full pages, the frontend (or a mobile app) calls API endpoints to read and modify data. Common styles include REST (resource-oriented URLs and HTTP methods) and others like GraphQL.

Critically, APIs are directly callable — anyone can send requests to them, not just the official frontend.

How it works

A frontend makes API requests (e.g. GET /api/orders, POST /api/orders) and renders the returned data. Because the API is reachable over the network, an attacker can call the same endpoints directly with crafted requests — bypassing the app's UI entirely. Each endpoint must therefore enforce its own authentication, authorization, and input validation. The API, not the frontend, is the true security perimeter for data operations.

Practical example

A mobile banking app calls GET /api/accounts/12345/balance. If the endpoint returns the balance based only on the account ID in the URL — without verifying the requester owns account 12345 — an attacker could change the ID to another account and read someone else's balance. This is a broken-object-level-authorization flaw, and it lives entirely in the API, independent of the app's interface.

Cybersecurity relevance

APIs concentrate an application's data operations, making them a prime target. Common API weaknesses include missing or weak authentication, broken object-level authorization (accessing others' data by changing an identifier), excessive data exposure, and lack of rate limiting. Because APIs are called directly, every endpoint must be secured independently. This lesson sets up the dedicated API Security module later in the path.

Common mistakes

  • Assuming only the official app calls the API, so endpoints can be left under-protected.
  • Relying on the frontend to restrict data, while the API returns more than needed.
  • Authorizing by identifier presence rather than verifying the requester owns or may access that object.

Key takeaways

  • An API is a set of directly callable backend endpoints (often REST/JSON) that the frontend uses to read and change data.
  • Because APIs are reachable directly, each endpoint must enforce its own authentication, authorization, and validation.
  • APIs are a major attack surface; broken object-level authorization and missing auth are common, high-impact flaws.

Check your understanding

  • Why can't an API rely on the frontend to keep it secure?
  • What is broken object-level authorization, and why is it an API-level (not frontend) problem?
FINISH THIS LESSON

Sign in to save your progress.