Skip to main content
Version: v1

API A8 - Injection

A8

Subcategories​

  • SQL Injection (SQLi) – CWE-89
  • NoSQL Injection (NoSQLi) – CWE-943
  • Command Injection (CMDi) – CWE-77
  • Remote Code Execution (RCE) – CWE-94
  • Custom Injection – Context-specific payload injection vectors

What is it?​

Injection vulnerabilities occur when untrusted user input is interpreted as executable code or commands by backend systems.

In APIs, this typically happens when input data is directly embedded into:

  • Database queries (SQL/NoSQL)
  • System commands
  • Interpreted code paths
  • Dynamic execution contexts

Lack of strict input validation and unsafe query construction allows attackers to manipulate execution logic, resulting in data exfiltration, privilege escalation, or full system compromise.

What are the common types of injection for APIs?​

SQL Injection (SQLi)​

  • Manipulating SQL queries to access or modify database data
  • Common in endpoints interacting with relational databases

NoSQL Injection (NoSQLi)​

  • Exploiting query structures in NoSQL databases (e.g., MongoDB operators like $ne, $gt)
  • Often bypasses authentication or filtering logic

Command Injection (CMDi)​

  • Injecting OS-level commands executed by the application server
  • Can lead to system compromise or lateral movement

Remote Code Execution (RCE)​

  • Injecting payloads that result in execution of arbitrary code
  • Often chained from deserialization or command injection flaws

Custom Injection​

  • Context-specific injections (e.g., LDAP, XPath, template injection)
  • Depends on backend technologies and data processing pipelines

Test case FAQs​

When is this test case applicable?​

  • All API endpoints accepting user-controlled input (query, path, headers, body)
  • High-risk for endpoints interacting with databases, file systems, or execution engines

How does it work?​

The test engine performs payload-based injection testing across input vectors:

  • Injects crafted payloads into parameters (e.g., ' OR 1=1--, $ne:null, ; ls)
  • Observes response anomalies (data leakage, errors, timing differences)
  • Detects execution indicators (unexpected output, system responses)
  • Correlates responses across payload variations to confirm exploitability

Detection signals include:

  • SQL/NoSQL error patterns
  • Response structure deviations
  • Time-based blind injection indicators
  • Execution side-effects (command output, file access)

What is the solution?​

  • Use parameterized queries / prepared statements
  • Enforce strict input validation and schema constraints
  • Apply output encoding and escaping where applicable
  • Avoid dynamic query or command construction
  • Use least privilege for database and system access
  • Implement WAF / API security controls for runtime protection
  • Continuously test APIs using automated security scanners

References​

Was this page helpful?