Aplicaciones web

Una aplicación web recibe mensajes y toma decisiones. Reservar un libro puede exigir sesión válida, permiso sobre la cuenta, un ejemplar disponible y una actualización coherente. La seguridad incluye todas esas reglas, además de la pantalla de acceso.

HTTP define mensajes y semántica de aplicación. Utiliza transporte subyacente: HTTP/3 emplea QUIC y versiones anteriores suelen usar TCP. HTTPS protege la comunicación, pero no decide quién edita un objeto ni garantiza reglas de negocio correctas.

Comprende el propósito de la solicitud

Una solicitud tiene método, destino, cabeceras y, a veces, cuerpo. Sus campos llevan identificadores, texto, evidencia de sesión y opciones. El nombre de un campo no demuestra que su valor sea fiable.

En una reserva ficticia, identifica libro, cuenta y acción deseada. El servidor debe obtener identidad fiable de una sesión validada, comprobar permisos y aplicar reglas. Una etiqueta de cuenta enviada no constituye prueba.

Un mapa de solicitudes documenta propósito, entradas, cambios, sensibilidad y permisos. Incluye lecturas y escrituras: puede haber divulgación no autorizada sin modificar el registro. Un código de respuesta correcto no demuestra autorización ni procesamiento empresarial correctos.

Autenticación y autorización

La Autenticación establece confianza en una cuenta. Una cookie puede mantener sesión; JWT es un formato; una clave API puede identificar una aplicación; un método con certificado prueba posesión según una configuración de confianza. Ninguno sustituye toda validación.

La Autorización decide si ese actor puede actuar sobre este recurso ahora. Puede aplicarse a usuarios autenticados o anónimos. Importan propiedad, rol, organización, etapa del proceso y otras reglas. Ocultar un botón ayuda a la interfaz, pero no impone permisos a una API.

Un socio puede reservar libros. ¿Puede editar todas las reservas?

No. El permiso para usar una función y el permiso sobre un objeto son decisiones distintas. El servicio debe comprobar propietario y roles legítimos del personal en cada acción protegida.

Los datos deben seguir siendo datos

Una Inyección permite que contenido no fiable influya en instrucciones o sintaxis. El intérprete determina la prevención: operaciones de base de datos parametrizadas, codificación de salida según contexto, API seguras y opciones dinámicas restringidas cumplen funciones distintas.

No existe una función de escape universal para SQL, HTML, órdenes y cualquier plantilla. Parametrizar tampoco cubre automáticamente identificadores u otros elementos que la API no admite como parámetros; requieren diseño y validación adecuados.

Archivos y solicitudes del servidor tienen límites adicionales. Una ruta o URL sintácticamente válida puede señalar un recurso no permitido. Restringe recursos y operaciones independientemente del análisis sintáctico.

Cada protección del navegador tiene una función

La Política de mismo origen limita el acceso de scripts entre orígenes, especialmente la lectura de respuestas. Permite ciertas solicitudes y recursos incrustados entre orígenes. CORS declara acceso seleccionado para navegadores; no sustituye autenticación ni autorización. Una lectura bloqueada no demuestra que la solicitud careciera de efectos.

Las cookies tienen protecciones distintas. Secure restringe transporte, HttpOnly limita acceso desde scripts y SameSite influye en el envío entre sitios. El comportamiento depende de reglas del navegador y configuración.

CSRF utiliza credenciales que el navegador añade automáticamente a una solicitud no deseada. Tokens adecuados, comprobaciones de origen y política de cookies ayudan a validar su legitimidad. XSS implica ejecución no autorizada de scripts. Puede realizar acciones o leer datos de la página aunque HttpOnly impida leer directamente la cookie. Robar cookies no es su único impacto.

Elige una lección para profundizar

Un hallazgo útil relaciona conducta observada, regla prevista, datos o acción afectados y corrección concreta. Distingue observaciones de suposiciones y conserva solo la evidencia depurada necesaria para explicarlo.

Sigue una petición a través de cinco decisiones

Considera una biblioteca ficticia. Lina pide cancelar la reserva R42. La sesión identifica a Lina, R42 pertenece a Jo y la política permite cancelar solo al propietario o a un bibliotecario. Lina tiene el rol de miembro. Estos datos bastan para resolver el permiso: rechazar esta cancelación.

La autenticación funcionó, pero solo aportó una entrada a la autorización. El identificador R42 selecciona el objeto; no establece una relación con Lina. El servidor debe evaluar actor, acción, recurso y política vigente antes de modificar el estado. También debe devolver únicamente información que el solicitante pueda recibir.

PrediceLa interfaz oculta el botón de cancelar R42. ¿Cambia eso la decisión del servidor?

La decisión sigue siendo rechazar. Ocultar una acción no disponible ayuda al usuario, pero la interfaz cliente no es la autoridad del servicio. La misma política debe cubrir navegador, móvil y otros clientes admitidos.

Añade ahora una cancelación permitida de una reserva de Lina. El permiso no resuelve la concurrencia: la reserva podría haberse completado ya. El servicio necesita una transición de estado definida y una actualización coherente. Si después muestra la explicación de Lina, ese texto necesita un contexto de salida apropiado. Si almacena la respuesta en caché, la política de uso compartido debe corresponder a su audiencia.

Una revisión útil sigue cinco preguntas: quién actúa, qué objeto interviene, qué acción está permitida ahora, cómo se interpretan los datos y dónde puede conservarse o compartirse el resultado. Los registros aportados establecen la decisión sobre R42; no demuestran que el código desplegado la aplique. Para eso hacen falta evidencias de implementación y verificación.