SECURITY 13 min

OWASP Top 10 Web y APIs: XSS, CSRF, SQLi y Cabeceras HTTP

Un análisis técnico de las vulnerabilidades web más críticas. Estrategias defensivas para securizar aplicaciones modernas: sanitización de entradas, cabeceras CORS estrictas y protección CSRF.

Escrito por Samir El Azem Crovetto • Senior Backend Engineer & DevSecOps

El Panorama de Amenazas Web y APIs en Entornos Empresariales

Las aplicaciones web modernas y las APIs RESTful constituyen la principal interfaz pública de las organizaciones y, por consiguiente, su superficie de ataque más expuesta. A pesar de los continuos avances en frameworks modernos y motores de ejecución, las vulnerabilidades clásicas del OWASP Top 10 y del OWASP API Security Top 10 continúan encabezando los informes de incidentes de seguridad e intrusiones corporativas.

La persistencia de estos vectores de ataque no se debe a la falta de herramientas criptográficas o de cortafuegos, sino a errores fundamentales en el saneamiento de datos de entrada, la asunción incorrecta de confianza en los clientes web y la omisión de cabeceras de seguridad HTTP defensivas a nivel de servidor y pasarela.

Para neutralizar estas amenazas de forma sistemática, es imprescindible implementar una estrategia de Defensa en Profundidad: combinar el saneamiento y parametrización estricta en el código fuente backend con el aislamiento contextual y las políticas de ejecución del navegador mediante cabeceras HTTP de última generación.

Arquitectura de Defensa en Profundidad: Inspección y Flujo Perimetral

La interacción entre el navegador web del usuario y el servidor backend debe incorporar múltiples capas de validación y contención antes de procesar cualquier transacción:

graph TD
    subgraph Browser_Client ["🌐 Navegador del Cliente"]
        User["Usuario / Atacante"]
        DOM["Árbol DOM & Contexto JS"]
        CSP_Engine["Motor de Evaluación CSP & Cabeceras"]
    end

    subgraph Edge_Gateway ["🛡️ Pasarela Perimetral (Reverse Proxy / WAF)"]
        WAF["WAF: Detección de SQLi / XSS"]
        HeaderInjector["Inyector de Cabeceras HTTP:<br/>HSTS, CSP, Frame-Ancestors, Permissions-Policy"]
    end

    subgraph Backend_Application ["⚙️ Aplicación Backend (Spring Boot / Node.js)"]
        CSRF_Filter["Filtro Anti-CSRF (SameSite + Double Submit Token)"]
        InputValidator["Validador Estricto de Esquema & Tipos"]
        ORM_DAL["Capa de Persistencia (Prepared Statements)"]
        Database[("Base de Datos Relacional / SQL")]
    end

    User -->|Petición HTTP con Payload| WAF
    WAF -->|Tráfico Limpio| CSRF_Filter
    WAF -.->|Payload Malicioso Detectado| Block["HTTP 403 Forbidden"]
    CSRF_Filter --> InputValidator
    InputValidator --> ORM_DAL
    ORM_DAL -->|Consulta Parametrizada| Database
    Database --> ORM_DAL
    ORM_DAL --> HeaderInjector
    HeaderInjector -->|Respuesta con Cabeceras Seguras| CSP_Engine
    CSP_Engine --> DOM

    classDef client fill:#e1f5fe,stroke:#0288d1,stroke-width:2px;
    classDef edge fill:#fff3e0,stroke:#f57c00,stroke-width:2px;
    classDef backend fill:#e8f5e9,stroke:#388e3c,stroke-width:2px;
    classDef block fill:#ffebee,stroke:#d32f2f,stroke-width:2px;

    class User,DOM,CSP_Engine client;
    class WAF,HeaderInjector edge;
    class CSRF_Filter,InputValidator,ORM_DAL,Database backend;
    class Block block;

1. Inyección SQL (SQLi): Parametrización y Errores en ORMs

La inyección SQL se produce cuando datos no confiables suministrados por el usuario se concatenan directamente en la construcción de una consulta SQL, alterando la estructura del comando ejecutado por el motor de base de datos.

El Antipatrón Clásico de Concatenación:

// Vulnerable: Concatenación directa de entradas de usuario
String query = "SELECT * FROM users WHERE username = '" + userInput + "' AND password = '" + password + "'";
Statement statement = connection.createStatement();
ResultSet rs = statement.executeQuery(query);

Si el atacante suministra admin' --, la condición se evalúa como verdadera y la contraseña se ignora, permitiendo el acceso administrativo no autorizado.

La Solución Cripto-Matemática: Consultas Parametrizadas (Prepared Statements)

En una consulta parametrizada, el motor de base de datos compila la estructura sintáctica de la consulta antes de enlazar los valores de los parámetros. Los datos del usuario se tratan exclusivamente como literales, impidiendo que el motor interprete caracteres especiales como delimitadores de comandos:

// Seguro: Parámetros tipados enlazados en tiempo de ejecución
String safeQuery = "SELECT id, username, email FROM users WHERE username = ? AND is_active = ?";
try (PreparedStatement pstmt = connection.prepareStatement(safeQuery)) {
    pstmt.setString(1, userInput);
    pstmt.setBoolean(2, true);
    try (ResultSet rs = pstmt.executeQuery()) {
        // Procesar resultados de forma segura
    }
}

Vulnerabilidades Ocultas en ORMs y Frameworks Modernos:

Un error frecuente es asumir que por utilizar Hibernate o Spring Data JPA la aplicación está automáticamente inmune a SQLi. Como detallamos en la guía de Spring Data JPA en producción, existen escenarios donde surgen vulnerabilidades críticas:

  • Concatenación en consultas JPQL/HQL (entityManager.createQuery("FROM Account WHERE iban = '" + iban + "'")).
  • Concatenación de cadenas al construir cláusulas dinámicas con la API CriteriaBuilder.
  • Uso de consultas nativas (@Query(value = "...", nativeQuery = true)) sin variables de enlace nombradas (:paramName).

2. Cross-Site Scripting (XSS): Codificación Contextual y Content Security Policy (CSP)

El Cross-Site Scripting permite a un atacante ejecutar código JavaScript arbitrario en el navegador de una víctima legítima, posibilitando el secuestro de tokens de sesión, la redirección a portales de phishing o la alteración del contenido de la página.

Tipologías de XSS:

  1. Reflected XSS: El payload malicioso viaja en la petición (por ejemplo, en un parámetro URL ?search=<script>...) y el servidor lo refleja inmediatamente en la respuesta HTML sin saneamiento.
  2. Stored XSS (Persistente): El payload se almacena en la base de datos (en un comentario de blog, perfil de usuario o ticket de soporte) y se sirve a todos los usuarios que visualicen el recurso.
  3. DOM-based XSS: La vulnerabilidad reside exclusivamente en el código JavaScript del cliente, cuando funciones peligrosas (sinks como innerHTML, document.write, o eval) procesan fuentes no confiables (sources como location.search o window.name).

Codificación de Salida Dependiente del Contexto (Context-Aware Encoding):

No basta con escapar caracteres como < o >. La codificación debe corresponderse con el contexto exacto donde se renderiza el dato dentro del documento HTML:

Contexto de Inserción Caracteres Peligrosos Técnica de Mitigación Obligatoria
Cuerpo HTML (<div>...</div>) & < > " ' / Entidades HTML (&lt;, &gt;, &quot;)
Atributo HTML (<input value="...">) Caracteres no alfanuméricos Codificación de atributo HTML (&#xHH;)
Bloque JavaScript (<script>var x = ...</script>) Caracteres de escape \, ", ', < Serialización JSON estricta (JSON.stringify)
Parámetro URL (<a href="/search?q=...">) Espacios, delimitadores de URL Codificación URL por porcentaje (encodeURIComponent)

La Barrera Defensiva Definitiva: Content Security Policy (CSP) con Nonces

Content Security Policy (CSP) es una cabecera de respuesta HTTP que permite restringir los orígenes desde los cuales el navegador puede cargar scripts, estilos, imágenes y fuentes, bloqueando la ejecución de scripts inyectados inline.

La configuración moderna recomendada en 2026 prescinde de listas de dominios permitidos (fácilmente eludibles mediante bypasses en CDNs compartidas) y adopta una política basada en Nonces Criptográficos:

Content-Security-Policy: 
  default-src 'none';
  script-src 'nonce-dGhpcyBpcyBhIHJhbmRvbSBub25jZQ==' 'strict-dynamic' https: 'unsafe-inline';
  style-src 'self' 'nonce-dGhpcyBpcyBhIHJhbmRvbSBub25jZQ==';
  img-src 'self' data: https:;
  font-src 'self';
  connect-src 'self' https://api.empresa.local;
  base-uri 'none';
  form-action 'self';
  frame-ancestors 'none';
  • Cada script legítimo debe incluir el atributo nonce="dGhpcy...", generado de forma criptográficamente aleatoria en cada solicitud HTTP por el servidor.
  • Cualquier script inyectado por un atacante carecerá del nonce válido de esa sesión específica y será bloqueado de inmediato por el motor del navegador, neutralizando el 99% de los ataques XSS.

3. Cross-Site Request Forgery (CSRF): SameSite y Double Submit Tokens

El CSRF explota la confianza que una aplicación web deposita en el navegador de un usuario autenticado. Un atacante induce a la víctima a visitar un sitio malicioso que emite una petición oculta hacia la aplicación bancaria o corporativa; el navegador incluye automáticamente las cookies de sesión del usuario, ejecutando transferencias o cambios de contraseña no consentidos.

Estrategia 1: Atributo SameSite en Cookies de Sesión

El estándar de cookies HTTP mitiga la mayoría de los escenarios CSRF mediante la directiva SameSite:

Set-Cookie: JSESSIONID=abc123xyz789; Path=/; Secure; HttpOnly; SameSite=Strict
  • SameSite=Strict: La cookie nunca se envía en peticiones originadas en sitios de terceros, ni siquiera al hacer clic en un enlace entrante. Ideal para paneles de administración y portales financieros.
  • SameSite=Lax: La cookie solo se envía en navegaciones de nivel superior mediante métodos HTTP seguros (GET). Protege ante peticiones POST de terceros.

Estrategia 2: Patrón Double Submit Cookie para APIs RESTful Stateless

En arquitecturas SPA y microservicios desacoplados donde no se mantiene estado de sesión en el servidor, se utiliza el patrón Double Submit Cookie:

  1. El servidor genera un token pseudoaleatorio criptográfico y lo envía al cliente en una cookie accesible por JS (XSRF-TOKEN).
  2. En cada petición mutacional (POST, PUT, DELETE), la aplicación frontend lee la cookie e incluye el mismo valor en una cabecera HTTP personalizada (X-XSRF-TOKEN).
  3. El servidor compara que el valor de la cabecera coincida con el valor de la cookie. Debido a la política del mismo origen (SOP - Same-Origin Policy), un sitio de terceros no puede leer la cookie del dominio ni forjar la cabecera HTTP personalizada.

4. Clickjacking y UI Redressing: De X-Frame-Options a frame-ancestors

El Clickjacking consiste en cargar la aplicación víctima dentro de un marco transparente (<iframe>) superpuesto visualmente sobre una página trampa. Cuando el usuario hace clic en lo que parece un botón inocente (un juego, un vídeo), en realidad está pulsando botones críticos de la aplicación embebida (como "Transferir Fondos" o "Autorizar Aplicación").

La Cabecera Histórica: X-Frame-Options

Durante años, el estándar de mitigación fue:

X-Frame-Options: DENY
# o bien
X-Frame-Options: SAMEORIGIN

Sin embargo, X-Frame-Options presenta severas limitaciones: no permite especificar listas de dominios autorizados de forma granular y no está estandarizada formalmente en las especificaciones W3C.

La Solución Moderna: Directiva frame-ancestors en CSP

La directiva frame-ancestors de Content Security Policy sustituye y anula a X-Frame-Options en todos los navegadores modernos:

# Bloquear completamente la incrustación en cualquier iframe
Content-Security-Policy: frame-ancestors 'none';

# Permitir incrustación exclusivamente desde el propio dominio
Content-Security-Policy: frame-ancestors 'self';

# Permitir incrustación desde un portal corporativo autorizado
Content-Security-Policy: frame-ancestors 'self' https://portal.empresa.local;

Si un atacante intenta incrustar la web en un iframe externo, el navegador aborta la carga del marco mostrando un error de política de seguridad, protegiendo al usuario de manipulaciones visuales.

5. Línea Base de Cabeceras de Seguridad HTTP en Producción

Para garantizar una postura de seguridad robusta, cualquier servidor web, API Gateway o proxy reverso en producción debe inyectar la siguiente línea base de cabeceras en todas las respuestas HTTP:

# Configuración recomendada para Nginx / Envoy / Express
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=(), payment=()" always;
add_header X-Frame-Options "DENY" always; # Fallback para clientes muy antiguos
  • Strict-Transport-Security (HSTS): Fuerza a los navegadores a comunicarse exclusivamente mediante HTTPS durante los próximos 2 años (max-age=63072000), previniendo ataques de degradación de protocolo (SSL Stripping).
  • X-Content-Type-Options: nosniff: Impide que el navegador intente adivinar (MIME sniffing) el tipo de contenido de una respuesta, bloqueando ataques donde un archivo de imagen malicioso se interpreta como ejecutable JavaScript.
  • Permissions-Policy: Desactiva el acceso a APIs de hardware sensibles (cámara, micrófono, geolocalización) para scripts de terceros o iframes.

Resumen y Checklist de Hardening Web y APIs

  • [x] Consultas SQL ejecutadas estrictamente mediante Prepared Statements parametrizados, evitando concatenaciones en ORMs.
  • [x] Codificación de salida contextual aplicada a todas las variables inyectadas en vistas HTML/JS.
  • [x] Content Security Policy (CSP) desplegada con Nonces criptográficos y directiva frame-ancestors.
  • [x] Cookies de autenticación configuradas con flags HttpOnly, Secure y SameSite=Strict/Lax.
  • [x] Protección CSRF implementada mediante tokens Double Submit para endpoints de mutación REST.
  • [x] Línea base completa de cabeceras HTTP (HSTS con preload, nosniff, Permissions-Policy) inyectada en el servidor perimetral.

Si necesitas auditar la seguridad web y de APIs de tu plataforma, implementar políticas CSP avanzadas o mitigar vulnerabilidades del OWASP Top 10 en tu stack corporativo, puedes consultar mis Servicios de Ciberseguridad y Consultoría o ponerte en contacto conmigo a través de Sobre mí.