Output Encoding

Problem

User-provided data containing special characters like <, >, or " is interpreted as HTML or JavaScript when rendered. Attackers inject malicious scripts through form inputs, URL parameters, or API responses that execute when displayed to other users.

Solution

Encode data appropriately for its destination context (HTML, JavaScript, URL) to prevent injection attacks. This ensures user content is treated as data rather than executable code.

Example

This example demonstrates HTML encoding to prevent XSS attacks by converting special characters to their safe HTML entity equivalents.

function encodeHTML(str) {
  return str
    // Replace & first to avoid double-encoding
    .replace(/&/g, '&')
    // Encode < to prevent opening tags
    .replace(/</g, '&lt;')
    // Encode > to prevent closing tags
    .replace(/>/g, '&gt;')
    // Encode quotes to prevent breaking out of attributes
    .replace(/"/g, '&quot;')
    .replace(/'/g, '&#x27;');
}

// Using textContent is safer - browser automatically encodes
element.textContent = userInput; // Safe - browser handles encoding

Benefits

• Prevents XSS attacks by ensuring user data is treated as data, not code.
• Provides context-aware encoding for HTML, JavaScript, and URL contexts.
• Works as a last line of defense even if input validation fails.
• Protects against injection attacks in all output contexts.

Tradeoffs

• Requires knowing the correct encoding for each context (HTML vs JS vs URL).
• Can double-encode if applied multiple times to the same data.
• May not handle all edge cases without a robust encoding library.
• Should be used alongside input validation, not as the only security measure.