# Seguridad en Oracle APEX: Estrategias para evitar inyecciones SQL y ataques XSS

> 💼 **Para Directores de TI y Tomadores de Decisiones**
> 
> *   **Problema de Negocio:** Las filtraciones de datos y accesos no autorizados destruyen la reputación de la marca; la seguridad proactiva previene fraudes y protege la confianza del usuario.
>     
> *   **Eficiencia Operativa:** Implementar defensas nativas en APEX reduce el tiempo de auditoría manual de código en un 70% y evita costosas correcciones de vulnerabilidades en producción.
>     
> *   **Nota para Desarrolladores:** Si eres desarrollador, ¡sáltate directamente al código de abajo!
>     

En nuestra [entrada anterior](https://insightsapex.vinnyum.tech/oracle-apex-mejores-practicas-esenciales) de ***APEX Insights*,** cubrimos las diez recomendaciones clave para construir aplicaciones APEX robustas y mantenibles. Ahora, es momento de profundizar en el pilar más crítico de todos: **la seguridad**.

Oracle APEX ofrece una arquitectura excepcionalmente segura por diseño, pero el código PL/SQL y JavaScript que escribimos puede introducir vulnerabilidades. Los dos ataques más comunes que enfrentaremos son la **Inyección SQL** (un ataque del lado del servidor) y el **Cross-Site Scripting (XSS)** (un ataque del lado del cliente).

Dominar las defensas contra estos ataques es el paso definitivo para llevar tus aplicaciones APEX a un nivel de clase mundial.

## El Enemigo del Servidor: Inyección SQL

La Inyección SQL ocurre cuando un atacante introduce código SQL malicioso a través de una entrada de usuario, haciendo que el servidor ejecute comandos no deseados (ej. borrar datos, obtener información confidencial).

### La Regla de Oro: Siempre Variables de Enlace (Bind Variables)

La defensa es simple y absoluta: **Nunca concatenes entradas de usuario directamente para construir una sentencia SQL.** Siempre utiliza variables de enlace (`:PXX_ITEM`) que fuerzan a la base de datos a tratar la entrada como *datos*, y no como *código*.

***Si aún usas concatenación en PL/SQL, ¡este es tu recordatorio final! Detente y refactoriza hoy mismo.***

### Práctica Deficiente (Vulnerable a Inyección SQL)

```sql
DECLARE
    l_user_id VARCHAR2(50) := :P1_USER_ID;
BEGIN
    -- El atacante puede inyectar: ' OR 1=1 --
    EXECUTE IMMEDIATE 'UPDATE users SET status = ''ACTIVE'' '
        || 'WHERE user_id = ''' || l_user_id || '''';
END;
```

### Práctica Recomendada (Segura con Variables de Enlace)

```sql
BEGIN
-- APEX y la BD manejan el valor de :P1_USER_ID como un dato seguro.
    UPDATE users SET status = 'ACTIVE' WHERE user_id = :P1_USER_ID;
END;
```

```sql
-- Para SQL dinámico, usa la API de APEX (APEX_EXEC).
APEX_EXEC.EXECUTE_SQL(
  p_sql_statement => 'UPDATE users SET status = :P_STATUS WHERE user_id = :P_USER_ID',
  p_bind_vars     => APEX_EXEC.T_BIND_VAR(
    APEX_EXEC.T_BIND_VAR_ROW('P_STATUS', 'ACTIVE'),
    APEX_EXEC.T_BIND_VAR_ROW('P_USER_ID', :P1_USER_ID)
  )
);
```

## El Enemigo del Cliente: Cross-Site Scripting (XSS)

El XSS ocurre cuando el código malicioso (generalmente JavaScript) se inyecta en la página web a través de un campo de entrada y se ejecuta en el navegador de otro usuario. Esto permite robar cookies de sesión o redirigir al usuario.

### La Solución Declarativa: Escapar Caracteres Especiales

APEX nos ofrece la defensa más poderosa contra XSS de forma **declarativa**. La regla es: **Siempre que muestres un valor ingresado por el usuario, debes "escapar" su contenido.**

*   **En Items de Página:** Utiliza el tipo de ítem adecuado. Si es solo texto, nunca uses un tipo que interprete HTML (como *Rich Text Editor*) si el contenido no es confiable.
    
*   **En Reportes (Clásicos o Interactivos):** Asegúrate de que la configuración de la columna tenga marcada la opción: **"Escape special characters"** (Escapar caracteres especiales).
    

![Configuración de Escapar Caracteres Especiales (Escape Special Characters) en Oracle APEX Page Designer](https://cdn.hashnode.com/res/hashnode/image/upload/v1761095316779/e33248f2-9495-4879-bec6-d5d65aa58fa5.png align="center")

### La Solución PL/SQL: La Función `APEX_ESCAPE.HTML_OUT`

Si estás generando código HTML en PL/SQL (por ejemplo, para un `htp.p` o en una función que devuelve un valor para ser mostrado), **siempre** debes sanear el contenido usando la API de APEX.

### Práctica Deficiente (Vulnerable a XSS)

```sql
-- MAL: No sanea el contenido, vulnerable a XSS
htp.p('Bienvenido, ' || :P1_USUARIO_NOMBRE);
```

### Práctica Recomendada (Segura con Escape HTML)

```sql
-- BIEN: Sanea la salida antes de enviarla al navegador
htp.p('Bienvenido, ' || APEX_ESCAPE.HTML_OUT(:P1_USUARIO_NOMBRE));
```

## Seguridad en el Flujo y Llamadas AJAX

La seguridad no termina en el código SQL; también se aplica a cómo navegas y ejecutas procesos en segundo plano.

### Uso Obligatorio de `apex.server.process()` para AJAX

Si tu código JavaScript necesita ejecutar un Proceso de Aplicación (AJAX) en el servidor, **nunca** intentes construir la llamada manualmente. Siempre utiliza la función `apex.server.process()` o [`apex.ajax.run`](http://apex.ajax.run)`()` de la API de JavaScript de APEX.

*   ***¿Por qué?*** *Estas funciones se encargan automáticamente de pasar el* ***checksum de la sesión*** *y otros valores de seguridad, asegurando que la llamada sea legítima y provenga de una sesión válida.*
    

```javascript
// Ejecución de un Proceso de Aplicación (AJAX)
// SIEMPRE usa apex.server.process() para enviar el checksum de seguridad

// 1. Definir los ítems de página a enviar al servidor
const items_a_enviar = {
  // Usamos $v() o apex.item().getValue() para obtener los valores
  // del DOM de forma segura
  x01: $v("P1_NUEVO_VALOR"),
  f01: ["valor1", "valor2"], // Envío de arrays de datos
};

// 2. Llamada segura al Process "PROCESO_GUARDAR_DATOS"
apex.server.process(
  "PROCESO_GUARDAR_DATOS", // Nombre del Process APEX definido en Shared Components
  {
    dataType: "json", // Tipo de datos esperado en la respuesta
    x01: items_a_enviar.x01,
    f01: items_a_enviar.f01,
  },
  {
    success: function (pData) {
      // Manejar la respuesta exitosa del servidor
      if (pData.success) {
        apex.message.showPageSuccess("Datos guardados exitosamente.");
      }
    },
    error: function (jqXHR, textStatus, errorThrown) {
      // Manejar errores
      apex.message.clearErrors();
      apex.message.showErrors([
        {
          type: "error",
          message: "Error al procesar: " + errorThrown,
          location: ["page"],
        },
      ]);
    },
  },
);
```

***Recuerda: Si es una llamada al servidor desde JavaScript, ¡siempre APEX API! Es la garantía de tu checksum de sesión.***

### 🛡️ Blindando AJAX Callbacks con Esquemas de Autorización (Authorization Schemes)

Usar `apex.server.process()` en el cliente es solo la mitad del trabajo. Si un usuario malintencionado puentea tu interfaz de usuario, aún podría intentar invocar directamente el **AJAX Callback** en el servidor.

Para evitar ejecuciones no autorizadas, debes asegurar el AJAX Callback a nivel de base de datos:

1.  **Protección Declarativa:** Asocia siempre un **Esquema de Autorización (Authorization Scheme)** nativo directamente al proceso AJAX Callback en el Page Designer de APEX.
    
2.  **Aserción Programática (PL/SQL):** Dentro del código del AJAX Callback, realiza una verificación de seguridad adicional utilizando la API nativa `APEX_AUTHORIZATION.IS_AUTHORIZED`.
    

A continuación, se muestra el patrón profesional en PL/SQL para blindar tus procesos AJAX:

```sql
-- AJAX Callback Seguro: "PROCESO_GUARDAR_DATOS"
DECLARE
    l_tiene_acceso BOOLEAN;
BEGIN
    -- 1. Aserción programática del esquema de autorización
    l_tiene_acceso := APEX_AUTHORIZATION.IS_AUTHORIZED(
        p_authorization_name => 'EDITAR_REGISTROS_VENTAS'
    );

    IF NOT l_tiene_acceso THEN
        -- Registrar el intento no autorizado en los logs y retornar un JSON seguro
        APEX_DEBUG.WARN(
            'Intento no autorizado de ejecución de AJAX callback por usuario: %s',
            :APP_USER
        );

        APEX_JSON.OPEN_OBJECT;
        APEX_JSON.WRITE('success', FALSE);
        APEX_JSON.WRITE('error', 'Acceso denegado: Privilegios insuficientes.');
        APEX_JSON.CLOSE_OBJECT;
        RETURN;
    END IF;

    -- 2. Procesamiento seguro de datos validados
    UPDATE leads_ventas
       SET estado = :x01
     WHERE id = :P1_ID_REGISTRO;

    APEX_JSON.OPEN_OBJECT;
    APEX_JSON.WRITE('success', TRUE);
    APEX_JSON.CLOSE_OBJECT;
EXCEPTION
    WHEN OTHERS THEN
        APEX_JSON.OPEN_OBJECT;
        APEX_JSON.WRITE('success', FALSE);
        APEX_JSON.WRITE('error', 'Ocurrió un error inesperado al procesar.');
        APEX_JSON.CLOSE_OBJECT;
END;
```

### Redirecciones Seguras con `APEX_UTIL.PREPARE_URL`

Cuando necesites construir un enlace o redirección a otra página de APEX, es fundamental incluir los controles de seguridad necesarios.

*   **Redirecciones Declarativas (la opción más segura):** La forma más sencilla y segura de redireccionar es a través de la configuración declarativa en un **Botón** o un **Proceso de Página** (Branching):
    
    1.  **Tipo de Redirección:** Seleccionar `Redirect to Page in this Application`.
        
    2.  **Página de Destino:** Indicar el número de página (ej., `#2`).
        
    3.  **Configuración de Seguridad:** En la sección **Set Items**, asignar los valores a los ítems de destino (`P2_DEPARTAMENTO`, `P2_ID_REGISTRO`). APEX se encarga automáticamente de:
        
        *   Sanear los valores.
            
        *   Generar y verificar el **Checksum de Sesión** para garantizar que la URL no haya sido alterada por el usuario.
            
    
    *   **Redirecciones en PL/SQL (Solo si es necesario):** Si la redirección debe ser lógica o condicional, utiliza las funciones `APEX_UTIL.PREPARE_URL` y `APEX_UTIL.REDIRECT_URL`. La primera garantiza que se incluya el **checksum** (hash de seguridad) para evitar la manipulación de la URL por parte del usuario.
        

```sql
DECLARE
    l_url VARCHAR2(4000);
BEGIN
    -- Uso de APEX_UTIL.PREPARE_URL para construir la URL con checksum
    l_url := APEX_UTIL.PREPARE_URL(
        -- Redirecciona a la página 2
        p_url    => 'f?p=' || :APP_ID || ':2:' || :APP_SESSION,
        -- Ítems de la página 2 que recibirán valores
        p_items  => 'P2_DEPARTAMENTO,P2_ID_REGISTRO',        p_values => 'VENTAS,' || :P1_ID_ACTUAL, -- Valores a pasar a los ítems
        p_checksum_type => 'SESSION' -- Genera el checksum basado en la sesión (Seguro)
    );

    -- Redirección final
    APEX_UTIL.REDIRECT_URL(p_url => l_url);
END;
```

## Conclusión

La seguridad en Oracle APEX es una responsabilidad compartida: el *framework* se encarga de la arquitectura (sesiones, autenticación), pero el desarrollador es el guardián de la codificación (PL/SQL y JavaScript). Al priorizar las Variables de Enlace, el Saneamiento de la Salida, los Esquemas de Autorización y la seguridad en los AJAX Callbacks, estarás blindando tus aplicaciones contra los ataques más comunes y demostrando un compromiso con la calidad profesional.

### 📚 Para Profundizar

¿Listo para profundizar? Continúa con nuestro siguiente artículo de la serie: [Seguridad Avanzada en Oracle APEX: Arquitectura para la Resiliencia](https://insightsapex.vinnyum.tech/seguridad-avanzada-oracle-apex) para dominar el modelado de amenazas, Web Credentials y listas de control de acceso (ACLs) a nivel empresarial.

* * *

## 📋 Lista de Verificación de 5 Minutos para Auditoría Rápida

Antes de registrar tus cambios o presionar el botón de "Desplegar", ten a mano o imprime esta lista de verificación rápida de 5 minutos para revisar tus páginas APEX:

*   \[ \] **Variables de Enlace (Bind):** ¿Busqué `EXECUTE IMMEDIATE` o SQL dinámico en mis procesos, paquetes o cálculos y verifiqué que todas las entradas de usuario utilicen variables de enlace (`:ITEM_NAME`) o `APEX_EXEC` en lugar de concatenación de cadenas?
    
*   \[ \] **Escapar Caracteres Especiales:** ¿Están todos los Interactive Grids, Interactive Reports y Reportes Clásicos configurados con **"Escape special characters" = SÍ** en aquellas columnas que renderizan texto ingresado por usuarios?
    
*   \[ \] **Protección de Estado de Sesión:** ¿Todos los ítems ocultos o de solo lectura que el usuario no debe modificar tienen configurada la opción **Session State Protection = Restricted**?
    
*   \[ \] **Autorización en AJAX Callbacks:** ¿Cada proceso de AJAX Callback en la página tiene un **Esquema de Autorización (Authorization Scheme)** asignado de forma declarativa y cuenta con una aserción programática con `APEX_AUTHORIZATION.IS_AUTHORIZED` al inicio de su ejecución en PL/SQL?
    
*   \[ \] **Redirecciones Seguras:** ¿Todas las redirecciones dinámicas se construyen usando `APEX_UTIL.PREPARE_URL` con `p_checksum_type => 'SESSION'` para garantizar la protección contra manipulación de parámetros en la URL?
    

*¡Pon a prueba tu código! ¿Cuál de estas vulnerabilidades has encontrado o solucionado en el pasado? Comparte tu experiencia o tu "regla de oro" de seguridad que no mencionamos aquí.*

*La seguridad evoluciona rápido. ¿Hay alguna nueva amenaza que los desarrolladores APEX debamos monitorear? Únete al debate en los comentarios.*

***¿Quieres más Insights APEX de este calibre? Suscríbete a nuestro blog para recibir notificaciones directas sobre rendimiento, desarrollo avanzado y, por supuesto, más seguridad.***

***No te pierdas la próxima entrega de APEX Insights, donde exploraremos como mejorar la experiencia del usuario en APEX. ¡Síguenos para no quedarte atrás!***

* * *

## 🚀 Eleva la Arquitectura de tu APEX

¿La deuda técnica está ralentizando tus procesos de base de datos o exponiendo brechas de seguridad? Ayudo a equipos de tecnología a construir aplicaciones robustas, scalables y seguras en Oracle APEX.

*   **Servicio Destacado:** [🔍 Solicita una Evaluación de Deuda Técnica en tu Backend](https://calendly.com/vinnyum/intro-call)
    
*   **Contacto Directo:** Conéctate conmigo en [LinkedIn](https://www.linkedin.com/in/vinny-jimenez/) para discutir las mejores prácticas arquitectónicas de tu equipo.
    

* * *

## Referencias

Para un estudio más profundo de estos temas, consulta las siguientes fuentes:

1.  [**Directrices de desarrollo seguro de Oracle APEX**](https://docs.oracle.com/en/database/oracle/apex/latest/htmig/securing-an-application.html)**:** La documentación oficial que detalla la configuración de seguridad y las APIs.
    
2.  [**Proyecto OWASP Top 10 (A03: Inyección y A07: XSS)**](https://owasp.org/www-project-top-ten/)**:** El estándar de la industria para comprender la amenaza.
    
3.  [**API de JavaScript de APEX**](https://docs.oracle.com/en/database/oracle/apex/24.2/aexjs/apex.server.html) **(**`apex.server.process`): Asegura que tus llamadas AJAX sean seguras con checksums.