Understanding APIs and Security Risks

# CHAPTER 2

Understanding APIs and Security Risks #

1. Introduction #

2. Learning Objectives #

• Define the "Attack Surface" of a REST API.

• Understand the core components of an API request that hackers target.

• Explain the concept of Threat Modeling.

• Identify the stages of a Secure Software Development Life Cycle (SSDLC).

• Recognize the difference between infrastructure vulnerabilities and application logic vulnerabilities.

3. Beginner-Friendly Explanation #

When building an API, the attack surface includes the URL, the HTTP Headers, the Query Parameters, and the JSON Body.

Threat Modeling is the process of sitting down with the bank's blueprints *before* it is built and asking, "If I were a bank robber, how would I break in?" You look at the blueprints and realize the vault shares a wall with a public restroom. You identify the threat, and you fix the blueprint by moving the vault. This is much cheaper and safer than building the bank and waiting for it to be robbed.

4. Real-World Attack Scenarios #

• The Query Parameter Hack: An e-commerce API has an endpoint: POST /checkout?discount_code=10OFF. An attacker realizes they can manipulate the URL to POST /checkout?discount_code=100OFF or ?price=0.01. If the backend blindly trusts the URL parameters without verifying them against the database, the attacker buys a TV for a penny.

• The Header Spoofing: An internal API trusts any request that comes with the header X-Forwarded-For: 127.0.0.1 (pretending to be the local server). An external attacker manually adds this header to their Postman request, bypassing the firewall and accessing admin data.

5. Security Examples (The Attack Surface) #

1. 1. URL Paths: /api/users/123 (Can I change 123 to 124?)

1. 2. Query Strings: ?role=user (Can I change it to ?role=admin?)

1. 3. Headers: Authorization: Bearer xyz (Can I use an expired token?)

1. 4. JSON Body: {"age": 25} (Can I send {"age": -50} or {"age": "DROP TABLE users"}?)

6. Vulnerable vs Secure Code Examples (Threat Modeling) #

Vulnerable Code:

<?php
$quantity = $_POST[&#039;qty']; // Attacker sends -10
$price = 50;
// Total becomes -500. The store ends up owing the attacker money!
$total_cost = $quantity * $price; 
?>

Secure Code (Mitigated via Threat Modeling):

<?php
$quantity = (int) $_POST[&#039;qty'];

// Validate the input strictly
if ($quantity <= 0 || $quantity > 5) {
    http_response_code(400);
    echo json_encode(["error" => "Invalid quantity."]);
    exit;
}

$total_cost = $quantity * 50;
?>

7. HTTP Examples #

PUT /api/v1/profile HTTP/1.1
Host: api.example.com
Content-Type: application/json

{
  "name": "John",
  "email": "john@example.com",
  "is_admin": true 
}

*If the API updates the entire database row based on the JSON body, the attacker just granted themselves admin privileges. This is called Mass Assignment.*

8. JSON Examples #

{
  "username": "a",
  "password": "a",
  "bio": "<script>alert(&#039;Hacked')</script>"
}

*If the API accepts this JSON and saves it to the database, it creates a Cross-Site Scripting (XSS) vulnerability for anyone who views this user's profile.*

9. PHP Examples (The Security Lifecycle) #

1. 1. Design: Define strict routing and required authentication for all endpoints.

1. 2. Develop: Use PHP's built-in filter_var() and PDO for secure database interactions.

1. 3. Test: Write automated PHPUnit or Postman tests that specifically send *malicious* data to ensure the API rejects it.

1. 4. Deploy: Configure the Apache/Nginx server to use HTTPS and secure headers.

10. Best Practices #

• Assume Breach / Assume Malice: Write your backend code under the assumption that the frontend has already been compromised and the user is actively trying to destroy your database.

• Implement Threat Modeling: Use methodologies like STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) during the planning phase.

• Minimize the Attack Surface: Do not expose API endpoints you do not need. If an endpoint is for internal testing, delete it before pushing to production.

11. Common Mistakes #

• Testing Only the "Happy Path": QA teams often only test if the API works when used correctly. Security requires testing how the API behaves when used *incorrectly*.

• Trusting Hidden Fields: Believing that data is safe because it comes from an invisible HTML <input type="hidden">. Hackers see all HTTP traffic.

12. Security Checklists #

• [ ] Have we identified all endpoints exposed to the public internet?

• [ ] What is the absolute worst thing an attacker could do with this specific endpoint?

• [ ] How are we validating every single parameter in the Request Body, URL, and Headers?

• [ ] Does this endpoint reveal unnecessary technical information in error messages?

13. Mini Exercises #

1. 1. List the four main parts of an HTTP request that make up the API "Attack Surface".

1. 2. Explain how changing a single number in a URL (like an ID) could be a security risk.

14. Practice Challenges #

15. MCQs with Answers #

16. Interview Questions #

• Q: Explain the concept of an API's Attack Surface to a non-technical manager.

• Q: What is Threat Modeling, and what is the STRIDE methodology?

• Q: Give an example of a vulnerability that exists in the application logic layer rather than the infrastructure layer.

17. FAQs #

18. Summary #

19. Next Chapter Recommendation #