Skip to main content

RESTful

A RESTful API is a way for different software systems to communicate over the internet using standard HTTP methods in a simple and consistent manner. It follows the principles of REST (Representational State Transfer), where everything is treated as a resource (like users, posts, or products) identified by URLs, and operations are performed using HTTP verbs such as GET (read), POST (create), PUT/PATCH (update), and DELETE (remove). RESTful APIs are stateless, meaning each request contains all the information needed to process it, and they commonly exchange data in formats like JSON. This design makes APIs scalable, easy to understand, and widely used in web and mobile applications.

Endpoint Extractor​

It is a simple JavaScript bookmarklet tool designed to help developers and security researchers extract API endpoints from the JavaScript loaded by a web application. You install it by creating a browser bookmark whose URL is the JavaScript code from the repository (found in the extract.js file). When you visit a web application and click the bookmarklet, it runs the script in the context of the page and opens a new window showing detected endpoints, typically API paths or URLs that the app might use.

This kind of tool is useful during API analysis or reconnaissance to quickly see what backend endpoints a front-end application calls without manually inspecting all loaded scripts.

Reference: Endpoint Extractor

Testing Guides​

Broken Access Control​

REST APIs are often vulnerable to broken access control because authorization checks are either missing, improperly implemented, or only enforced on the client side. When access control validation is weak, users can access resources or perform actions beyond their intended privileges by manipulating requests, parameters, or endpoints.

These issues are testable by systematically verifying role-based access, object-level authorization, and permission boundaries across API endpoints to ensure that every request is properly authenticated and authorized on the server side.

Reference following for BAC issues testing:

  • Authentication and Authorization

JWT Attacks​

APIs generally use JWT (JSON Web Tokens) for authentication and access control, which makes JWT handling a critical area to test for security flaws. Misconfigurations such as weak signing algorithms, missing signature verification, improper token validation, or insecure claims handling can lead to privilege escalation and unauthorized access.

By applying standard JWT testing techniques, including tampering with token claims, changing algorithms, testing token expiration, and verifying signature enforcement, we can identify and validate JWT-related vulnerabilities that directly impact API access control security.

Reference following for JWT vulnerabilities:

  • JWT Attacks

Information Disclosure​

Sometimes API endpoints are insecurely coded and accidentally deployed into production, leading to critical information disclosure issues. In such cases, sensitive endpoints like /api/reset_password may directly return the password reset token digest, unique reset value, or even the full reset link in the API response instead of securely sending it via email.

Similar flaws also occur in OTP-based authentication, where the API responds with the actual OTP code or validation data intended only for the user. These misconfigurations completely break the security model of account recovery and authentication flows, making account takeover trivial for attackers without needing access to email, SMS, or user devices.

Examples:

  1. https://hackerone.com/reports/173551
  2. https://hackerone.com/reports/2635315

Downgrading API Versions​

Sometimes APIs are structured with versioned paths such as /v2/api/reset_password, where the production version is expected to have proper security controls and no information disclosure issues like those discussed earlier.

However, if an attacker changes the version number (for example, from v2 to v1), they may discover that an older API version is still active, improperly secured, or never fully deprecated. In many cases, developers forget to remove legacy endpoints or update their logic, which means vulnerable behaviors, such as leaking reset tokens or OTP values, can still be exploited through /v1 endpoints, even though the newer version appears secure. This makes API version downgrading a common and effective technique during security testing.

Filters Bypasses​

Flawed RegEx​

Some applications restrict registration to a specific email domain (for example, only addresses ending in @targetapp.com). But if the validation uses a flawed regex or weak string checks (like checking whether the input contains @targetapp.com instead of properly enforcing it at the end), attackers can bypass the control using crafted emails such as email@targetapp.com@attackeremail.com, email@targetapp.com.attackeremail.com or email@targetappXcom. In these cases, the app may mistakenly treat the address as belonging to the allowed domain, even though the real domain is controlled by the attacker, which can lead to unauthorized registration, access to internal-only features, or privilege abuse.

Validation bypass using Unicode​

APIs often assume inputs are simple ASCII strings, but Unicode characters can be abused to bypass validation, filtering, and security checks when normalization is not handled correctly. If validation logic, regex checks, or blacklist/whitelist rules operate on raw input while the backend logic processes a normalized version (or vice versa), attackers can sneak malicious or restricted values past defenses.

Common Unicode-based bypass techniques include:

  • Homoglyph attacks: Using visually similar Unicode characters to bypass string or domain checks.
    Example: replacing a with Cyrillic а (U+0430) so admin looks correct to humans but fails strict comparisons.
  • Unicode normalization issues (NFC/NFD): Characters can be represented in multiple valid forms. A regex may validate one form, while the application logic interprets another, bypassing restrictions.
  • Unicode whitespace characters: Non-standard spaces (e.g., U+00A0, U+200B) can bypass trimming or splitting logic, allowing usernames or roles like admin\u200B.
  • Unicode separators in emails and paths: Using characters such as U+FF0E (full-width dot) or U+2215 (division slash) to bypass domain or path validation while still being interpreted correctly downstream.
  • Case-folding inconsistencies: Unicode case conversion behaves differently across languages (e.g., Turkish İ/i), which can bypass case-insensitive checks for usernames or roles.

Example:
An API blocks registration with username admin, but fails to normalize Unicode input:

admin        → blocked
admіn        → allowed (uses Cyrillic “і”)
admın        → allowed (uses Dotless "ı")
info

https://shazzer.co.uk/tools/unicode-table

Improper Request Parsing​

Sometimes poorly coded API endpoints return sensitive data or send reset tokens to unintended recipients. For example, an API might accept a JSON body like:

{"username": "admin", "email": "admin@target.com"}

and correctly sends a reset token email to admin@target.com.
But if the implementation doesn’t validate the email parameter strictly, attackers might send:

{"username": "admin", "email": ["admin@target.com", "attacker@target.com"]}

In this case, the API treats the email field as an array, and without proper validation, the backend might process both entries, resulting in reset tokens being sent to the attacker’s address too. The attacker can then use the token from their inbox to reset the admin’s password and take over the account.

This type of issue arises from improper request parsing or validation logic, allowing arrays where only a single string should be allowed.

Example:

Changing of Content-Type Header​

Changing the Content-Type of a request (for example, from application/x-www-form-urlencoded or application/xml to application/json, or vice versa) can uncover additional attack vectors because different parsers, validators, and code paths may be triggered on the backend. Many applications apply security checks only for one expected format, leaving others loosely validated or entirely unprotected. Common examples include:

  • Authentication / authorization bypass: Access-control checks applied to form data may be skipped when the same parameters are sent as JSON, allowing unauthorized actions.
  • Input validation bypass: Server-side validation (regex, length checks, type checks) may be enforced for JSON but not for XML (or vice versa), enabling payload manipulation.
  • Parameter pollution & type confusion: A field expected as a string may be parsed as an array or object in JSON, leading to logic flaws (e.g., password reset email array abuse).
  • Mass assignment vulnerabilities: JSON bodies may allow extra fields to be injected (like role=admin) that are ignored or filtered in form-encoded requests.
  • Parser-specific attacks: Switching to XML may expose XXE issues, while JSON may reveal deserialization or schema-validation flaws.

HTTP Method Confusion​

Changing the HTTP verb can trigger different logic paths.

  • GET vs POST vs PUT vs PATCH
  • Some APIs block POST but forget to secure PUT
  • DELETE allowed without auth while POST is protected

Example:

POST /api/user/123/delete  → blocked
DELETE /api/user/123       → allowed

Parameter Pollution (HPP)​

Supplying the same parameter multiple times can override or confuse validation.

role=user&role=admin

or in JSON:

{ "role": "user", "role": "admin" }

Some frameworks take first value, others take last.

Header-Based Logic Abuse​

Some APIs trust headers too much.

  • X-Forwarded-For
  • X-Original-URL
  • X-HTTP-Method-Override

Example:

X-HTTP-Method-Override: DELETE
X-HTTP-Method-Override: PUT
X-HTTP-Method-Override: POST
...

Serialization / Deserialization Bugs​

Switching formats can trigger insecure deserialization paths.

  • JSON → YAML
  • JSON → XML
  • Protobuf fallback

Leads to RCE or auth bypass in extreme cases.