Secure Coding & OWASP Top 10 for Backend · Lekcja

Cross-Site Scripting (XSS) w backendzie

Poznaj sposoby, w jakie XSS może wynikać z podatności backendu, oraz strategie prawidłowego kodowania i walidowania danych wyjściowych.

Cross-Site Scripting (XSS) w backendzie to bezpłatna lekcja Secure Coding & OWASP Top 10 for Backend na CoddyKit. To lekcja 3 z 4. Możesz przeczytać całą lekcję poniżej za darmo — a potem ćwiczyć ją interaktywnie w przeglądarce z wbudowanym edytorem kodu i tutorem AI dostępnym 24/7. To część ścieżki edukacyjnej Secure Coding & OWASP Top 10 for Backend, a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs Secure Coding & OWASP Top 10 for Backend zawiera 4 lekcji w sumie.

Części tej lekcji nie zostały jeszcze przetłumaczone i są wyświetlane po angielsku.

XSS from a Backend Perspective

Cross-Site Scripting (XSS) is a type of security vulnerability that allows attackers to inject malicious scripts into web pages viewed by other users.

While XSS attacks execute in the user's browser (client-side), the root cause often lies in how the backend application handles, stores, and outputs user-supplied data.

Backend's Role in XSS

Your backend application is responsible for managing user data. This includes:

Receiving input from users.
Storing that input (e.g., in a database).
Retrieving and sending that input back to browsers for display.

If the backend fails to properly process or 'sanitize' this data before sending it to the browser, it creates an XSS vulnerability.

Reflected XSS via Backend

Reflected XSS occurs when a backend application immediately returns user input in its response without proper encoding, and a browser then renders it.

Think of a search page where your search term is echoed back in the results. If the search term contains malicious script, and the backend doesn't handle it, the script runs.

Stored XSS via Backend

Stored XSS is often more severe. Here, malicious user input is:

Received by the backend.
Persisted (e.g., saved in a database, file system).
Later retrieved and displayed to other users or even administrators.

Examples include vulnerable comment sections, forum posts, or user profile fields where data is saved and then rendered without proper protection.

Vulnerable Backend Output

Consider this simplified Java example. It takes user input and directly embeds it into the HTML response. Try running it with some malicious input!

public class VulnerableOutput {
  public static void main(String[] args) {
    // Imagine this is user input from a web request
    String userInput = "<script>alert('XSS Attack!');</script>"; 
    
    System.out.println("<html><body>");
    System.out.println("<h1>Welcome, " + userInput + "!</h1>"); // Direct output
    System.out.println("</body></html>");
  }
}

The Problem: Code Execution

When the backend directly outputs user input like in the previous example, the browser interprets it as part of the HTML structure.

If the userInput contained <script>alert('XSS Attack!');</script>, the browser would execute the JavaScript code within the script tags.

This allows attackers to:

Steal cookies (session hijacking).
Deface websites.
Redirect users to malicious sites.
Execute arbitrary actions on behalf of the user.

Defending with Output Encoding

The primary defense against XSS, especially for data originating from the backend, is output encoding.

Output encoding converts special characters (like <, >, &, ", ') into their safe HTML entity equivalents (e.g., <, >).

This ensures the browser treats the input as plain text, not executable code.

Secure Backend with Encoding

Here's how you can implement a basic HTML encoding function in Java to prevent XSS. Many web frameworks provide built-in, more robust encoding utilities.

public class SecureOutput {
  // A simplified HTML encoder
  public static String htmlEncode(String input) {
    if (input == null) return "";
    return input
      .replace("&", "&amp;")
      .replace("<", "&lt;")
      .replace(">", "&gt;")
      .replace("\"", "&quot;")
      .replace("'", "&#x27;")
      .replace("/", "&#x2F;");
  }

  public static void main(String[] args) {
    String userInput = "<script>alert('XSS Attack!');</script>"; // Malicious input
    String encodedInput = htmlEncode(userInput); // Apply encoding!

    System.out.println("<html><body>");
    System.out.println("<h1>Welcome, " + encodedInput + "!</h1>"); // Safe output
    System.out.println("</body></html>");
  }
}

Input Validation vs. Encoding

It's important to distinguish between:

Input Validation: Checks if data is valid and safe *before* processing or storing (e.g., ensuring an email is in correct format, limiting length). This helps with overall data integrity and other attack types.
Output Encoding: Makes data safe for display *after* retrieval from the backend. This is the direct and crucial defense against XSS.

Both are vital for a secure application, but output encoding is your final safeguard against XSS when rendering user-controlled content.

XSS Defense Check

A social media platform's backend stores user posts in a database. When another user views a post, the backend retrieves and displays it. Which is the most effective measure to prevent XSS?

Recap: Guarding Against XSS

In this lesson, we learned that:

XSS vulnerabilities often originate from backend applications that improperly handle user-supplied data.
Both Reflected and Stored XSS rely on the backend sending unencoded malicious input to the browser.
The most critical defense is output encoding, which converts special characters into safe HTML entities before any user-controlled data is rendered.
Combining robust input validation with consistent output encoding provides the best protection against XSS.

Często zadawane pytania

Czy lekcja „Cross-Site Scripting (XSS) w backendzie” jest bezpłatna?

Tak — pełny tekst „Cross-Site Scripting (XSS) w backendzie” jest dostępny za darmo tutaj w sieci. Aby ćwiczyć ją interaktywnie (wbudowany edytor kodu i tutor AI dostępny 24/7) i odblokować resztę kursu Secure Coding & OWASP Top 10 for Backend, przejdź na CoddyKit PRO. Kurs Secure Coding & OWASP Top 10 for Backend zawiera 4 lekcji w sumie.

Co nauczysz się w „Cross-Site Scripting (XSS) w backendzie”?

Poznaj sposoby, w jakie XSS może wynikać z podatności backendu, oraz strategie prawidłowego kodowania i walidowania danych wyjściowych. Ćwiczysz Secure Coding & OWASP Top 10 for Backend z praktycznym kodem, który uruchamiasz bezpośrednio w przeglądarce, a tutor AI dostępny 24/7 odpowiada na Twoje pytania podczas pracy nad lekcją.

Czy potrzebuję doświadczenia, aby zacząć Secure Coding & OWASP Top 10 for Backend?

Nie wymagamy żadnego doświadczenia. Secure Coding & OWASP Top 10 for Backend w CoddyKit jest strukturyzowany dla początkujących i zaawansowanych użytkowników, więc możesz zacząć tutaj lub od początku i uczyć się w swoim tempie. To lekcja 3 z 4.

Ile czasu zajmuje lekcja „Cross-Site Scripting (XSS) w backendzie”?

Większość lekcji CoddyKit trwa około 5–10 minut. Każda lekcja to mały, interaktywny krok, dzięki czemu robisz systematyczne postępy i zawsze wracasz dokładnie do tego samego miejsca — na webie i w aplikacji.

Czy mogę pisać i uruchamiać kod w tej lekcji Secure Coding & OWASP Top 10 for Backend?

Tak. Każda lekcja Secure Coding & OWASP Top 10 for Backend zawiera wbudowany edytor kodu, więc piszesz i uruchamiasz prawdziwy kod bezpośrednio w przeglądarce i od razu otrzymujesz sprzężenie zwrotne od AI — bez konfiguracji na komputerze.

Wszystkie lekcje w tym kursie

← Powrót do Secure Coding & OWASP Top 10 for Backend