Panorama tecnológico: Cómo funciona una aplicación web
Objetivos: Al terminar este tema, podrás…
- Explicar qué es una aplicación web y cómo están organizadas sus partes
- Describir qué hace el frontend, el backend, la base de datos y la nube
- Entender qué es una API y por qué es el componente más crítico para la seguridad
- Identificar las preguntas de seguridad correctas para cada capa del sistema
- Colaborar efectivamente con ingenieros de software e IA en el diseño de tu proyecto
En el proyecto de este semestre trabajas junto a estudiantes de Ingeniería de Software o de Inteligencia Artificial. Ellos construyen la aplicación; tu trabajo es analizarla desde la perspectiva de seguridad, y para hacerlo bien necesitas entender primero qué están construyendo. Esta clase te da el vocabulario y los conceptos que vas a necesitar para entender las decisiones de arquitectura que toma tu equipo, para ubicar en qué parte del sistema pueden aparecer los problemas de seguridad que ya estudiaste (el modelado de amenazas de la clase 04, el OWASP Top 10 de la clase 05, el control de acceso de la clase 06) y para hacer las preguntas correctas durante el diseño, antes de que cambiar algo salga caro.
Apertura: briefing de la investigación
Antes de que nadie te explique qué es un frontend o qué es un backend, vas a ir a buscarlos por tu cuenta. Toda aplicación web moderna separa lo que el usuario puede ver y tocar de lo que ocurre en otro lugar que el usuario no controla, y esa separación deja huellas que cualquiera puede observar con las herramientas que ya trae instalada su navegador, sin que nadie tenga que explicar antes cómo se llama lo que se está viendo. Hoy trabajas en grupo sobre un sitio web real, y tu punto de partida es la observación, no la definición.
Actividad: investigación de arquitectura real
La observación de la apertura fue apenas el primer vistazo. Ahora tu grupo profundiza en el mismo sitio, buscando específicamente algo que viaje en formato JSON entre el navegador y el servidor, y algo que le llame la atención: una petición inesperada, un dato que no esperaba ver, una URL que revela cómo está construido el sitio por dentro. La segunda parte del segmento es ponerlo en orden: cada grupo organiza lo que vio antes de compartirlo con el resto de la clase.
Galería de hallazgos
Cada uno de los cinco grupos exploró un sitio distinto, así que nadie en el salón tiene el panorama completo todavía. La puesta en común junta las cinco piezas: qué encontró cada grupo, qué patrones se repiten entre sitios tan distintos como un portal del Estado y un banco, y qué preguntas quedan abiertas antes de que la siguiente sección les ponga nombre a las cosas que ya vieron.
Teoría: cómo está armada una aplicación web
El modelo cliente-servidor
Lo que acabas de observar en la actividad tiene un nombre: el modelo cliente-servidor. Toda aplicación web funciona con la misma lógica básica que tu grupo encontró en la pestaña Red: hay una parte que pide y una parte que responde.
TÚ EL SISTEMA
[Navegador] ──── "dame la página" ──────────► [Servidor]
[Navegador] ◄─── "aquí está la página" ────── [Servidor]
El cliente es cualquier programa que hace peticiones: un navegador, una aplicación de celular, o incluso otro programa que corre en un servidor. El servidor es el programa que espera esas peticiones y las responde. Esta interacción ocurre miles de veces por segundo en cualquier aplicación que uses: cada vez que abres una red social, buscas algo en un buscador o haces clic en un botón, tu dispositivo genera peticiones que viajan a un servidor y regresan con una respuesta.
Esa separación importa para la seguridad porque cada petición que sale del cliente es una oportunidad para que alguien interfiera, y cada respuesta del servidor puede llevar datos que necesitan protección. El modelo cliente-servidor es la base sobre la que se construye toda la seguridad web.
Cuando abres la aplicación de tu banco en el celular y consultas tu saldo, ¿qué es el cliente y qué es el servidor en esa interacción? ¿Qué petición hace el cliente y qué le responde el servidor?
Las tres capas de una aplicación
La mayoría de aplicaciones web modernas reparten su trabajo en tres capas:
┌──────────────────────────────────────────────────────────┐
│ Lo que VE el usuario │
│ │
│ FRONTEND │
│ (páginas web, botones, formularios) │
└──────────────────────────────┬───────────────────────────┘
│ peticiones / respuestas
┌──────────────────────────────▼───────────────────────────┐
│ La lógica del sistema │
│ │
│ BACKEND │
│ (reglas de negocio, autenticación, procesamiento) │
└──────────────────────────────┬───────────────────────────┘
│ consultas / datos
┌──────────────────────────────▼───────────────────────────┐
│ Los datos guardados │
│ │
│ BASE DE DATOS │
│ (usuarios, transacciones, contenido) │
└──────────────────────────────────────────────────────────┘
En la literatura técnica a estas tres partes también se les llama, en ese mismo orden, capa de presentación, capa de lógica y capa de datos: los tres nombres describen exactamente lo mismo que acabas de ver como frontend, backend y base de datos.
El frontend es todo lo que aparece en el navegador: el diseño de la página, los botones, los formularios donde escribes. Está construido principalmente con HTML (la estructura de la página), CSS (el aspecto visual) y JavaScript (el comportamiento interactivo). El código del frontend corre en el navegador del usuario, lo que tiene una implicación de seguridad fundamental: cualquier usuario puede verlo, modificarlo y manipularlo. Por eso nunca puedes confiar en que el frontend proteja algo de verdad; toda verificación que importa debe ocurrir en el backend.
Un compañero de tu equipo propone validar los formularios solo en el frontend (en JavaScript) para "no sobrecargar el servidor". ¿Qué le responderías desde la perspectiva de seguridad?
El backend es el programa que corre en un servidor, invisible para el usuario: es donde ocurren las cosas importantes, como verificar si una contraseña es correcta, calcular el precio de un pedido o decidir qué información puede ver cada usuario. Recibe peticiones del frontend, las procesa según las reglas del sistema, consulta la base de datos si hace falta, y envía la respuesta de vuelta. Los ingenieros de software de tu equipo probablemente usarán lenguajes como Python (con marcos de trabajo como Django o FastAPI), JavaScript con Node.js, Java o Go; no necesitas memorizar la lista, solo reconocer que son formas distintas de escribir la misma capa de lógica. El backend es la última línea de defensa: si no verifica permisos, no importa que el frontend oculte un botón, porque quien ataca puede enviar la petición directamente; si no valida los datos que recibe, queda abierto a la inyección que estudiaste en la clase 05. Todas las vulnerabilidades del OWASP Top 10 que viste en esa clase viven en esta capa.
La base de datos guarda y organiza la información de forma persistente: cuando apagas el servidor los datos siguen ahí, y cuando lo vuelves a encender están donde los dejaste. Existen dos grandes tipos:
| Tipo | Cómo organiza los datos | Cuándo se usa | Ejemplo |
|---|---|---|---|
| Relacional (SQL) | En tablas con filas y columnas, como una hoja de cálculo | Datos estructurados con relaciones claras (usuarios, pedidos, productos) | PostgreSQL, MySQL |
| No relacional (NoSQL) | En documentos, listas o grafos más flexibles | Datos variados o sin estructura fija | MongoDB, Redis |
Para tu proyecto, lo más probable es que uses una base de datos relacional; sus consultas se escriben en el lenguaje SQL, y de ahí viene la vulnerabilidad de inyección SQL que practicaste en el laboratorio de la clase 05.
Cómo se comunican las capas: las APIs
Con las tres capas identificadas, falta explicar cómo se hablan entre sí, y este es el concepto más importante de la clase para la seguridad. Una API (application programming interface, interfaz de programación de aplicaciones) es un conjunto de instrucciones que define cómo un programa puede pedirle algo a otro programa. Piénsalo como ir a un restaurante: no entras a la cocina a preparar tu propia comida, le dices al mesero lo que quieres siguiendo el protocolo del menú, el mesero se lo transmite a la cocina, y la cocina te devuelve lo que pediste. El mesero es la API.
API: el mesero
[Frontend] ──── "quiero los datos del usuario 42" ────► [Backend]
[Frontend] ◄─── { "nombre": "Ana", "email": "..." } ─── [Backend]
En la práctica, las APIs web funcionan así: el frontend envía una petición HTTP al backend con una URL específica, esa petición puede incluir datos (en un formulario o en el cuerpo de la solicitud), y el backend procesa la petición y devuelve una respuesta, normalmente en un formato llamado JSON. Se ve así:
{
"usuario": {
"id": 42,
"nombre": "Ana García",
"email": "ana@ejemplo.com",
"rol": "estudiante"
}
}Es texto estructurado que tanto el frontend como el backend leen y generan con facilidad; si tu grupo encontró tráfico JSON durante la actividad de hoy, eso era justamente esto yendo y viniendo entre el navegador y el servidor.
Cada función de la API tiene una URL específica llamada endpoint:
| Endpoint | Método | Qué hace |
|---|---|---|
/api/usuarios/42 | GET | Obtener datos del usuario 42 |
/api/usuarios | POST | Crear un nuevo usuario |
/api/pedidos/7/cancelar | POST | Cancelar el pedido 7 |
/api/productos | GET | Listar todos los productos |
La API es la superficie de ataque más importante de una aplicación web: todo lo que alguien puede hacer contra un sistema pasa por ahí. Las vulnerabilidades de referencia insegura a objetos (IDOR) que viste en la clase 05, como cambiar el número en una URL para ver datos de otra persona, ocurren exactamente aquí, y el control de acceso que estudiaste en la clase 06 se implementa en este mismo lugar.
La nube
Todo lo anterior (frontend, backend y base de datos) tiene que correr en alguna máquina física, y ahí entra el último concepto que falta: la nube. Cuando alguien dice que una aplicación “está en la nube” se refiere a que el servidor que responde sus peticiones es una máquina alquilada a una empresa dedicada a tener miles de servidores disponibles para que otros los usen, en vez de una máquina que la propia empresa compró y guarda en un cuarto propio. Qué proveedores existen y cómo se reparte entre ese proveedor y tu equipo la responsabilidad de protegerla queda para la lectura disponible al final de este capítulo.
Así se ve, en conjunto, la arquitectura típica de un proyecto académico como el tuyo:
┌────────────────────────────────────────────────────────────────┐
│ INTERNET │
└───────────────────────────────┬────────────────────────────────┘
│
┌─────────────────▼──────────────────┐
│ FRONTEND │
│ (app web o móvil) │
│ Construido por: Ing. de Software │
└─────────────────┬──────────────────┘
│ peticiones API (HTTPS + JSON)
┌─────────────────▼──────────────────┐
│ BACKEND / API │
│ (lógica de negocio) │
│ Construido por: Ing. de Software │
│ o Ing. de IA (modelos de ML) │
└──────┬───────────────────┬──────────┘
│ │
┌────────────▼────────┐ ┌─────▼──────────────┐
│ BASE DE DATOS │ │ SERVICIO EXTERNO │
│ (datos del sistema)│ │ (opcional: APIs │
│ │ │ de terceros, IA) │
└─────────────────────┘ └────────────────────┘
Tu trabajo como ingeniero de seguridad es recorrer este diagrama y preguntarte, en cada punto, qué puede salir mal.
Cómo fluye una petición web, en corto
Con las cuatro piezas sobre la mesa (cliente, backend, base de datos y la nube donde vive todo esto), vale la pena recorrer, aunque sea rápido, qué pasa cuando alguien inicia sesión en una aplicación. El navegador arma una petición HTTP con el usuario y la contraseña y la envía por HTTPS, el protocolo cifrado que impide que alguien en el camino la lea. El backend recibe esa petición, compara el hash de la contraseña con el que tiene guardado (la razón de por qué se guarda como hash y no en texto plano la viste en la clase 05), y si coincide genera un token que el frontend guarda y usa en cada petición siguiente para no tener que volver a pedir la contraseña; el manejo seguro de ese token es justamente lo que trabajaste en la clase 06. La versión completa de estos pasos, con cada punto donde algo puede fallar de seguridad, está en la lectura disponible al final de este capítulo.
Preguntas de seguridad por capa y caso de estudio
Con el vocabulario ya puesto, quedan las preguntas que de verdad importan cuando diseñas o revisas la arquitectura de tu proyecto. Cada capa tiene una pregunta que pesa más que las demás.
Sobre el frontend, la pregunta más importante no es si valida los formularios (eso ayuda a la experiencia del usuario, pero nunca protege nada de verdad), sino si guarda información sensible en el navegador, como un token de sesión en un lugar donde cualquier script que se cuele pueda leerlo.
Sobre el backend y la API, la pregunta que más veces vas a repetir en tu proyecto, y la que más veces se te va a olvidar hacer, es si cada endpoint verifica que quien pide algo tiene permiso para pedir justamente eso. No basta con que el sistema sepa quién eres (autenticación); tiene que además decidir, en cada petición, si tú específicamente puedes ver o modificar ese recurso en particular. Un endpoint que solo revisa que exista una sesión iniciada, sin revisar de quién es el dato que se está pidiendo, es exactamente el error que viste hoy al explorar el sitio de tu grupo: cambiar un número en la URL nunca debería darte acceso a algo que no es tuyo.
Una aplicación de mensajería tiene el endpoint
GET /api/mensajes/conversacion/789. Al iniciar sesión, el frontend hace esta petición y muestra los mensajes. ¿Qué pregunta de seguridad crítica deberías hacerle al equipo sobre este endpoint?
Sobre la base de datos, la pregunta central es quién tiene acceso a ella además del backend: cada conexión adicional, cada panel de administración expuesto, es una puerta más que alguien tiene que vigilar.
Este último error, el de la pregunta sobre el backend, es tan común que tiene un ejemplo que se repite cada semestre en proyectos universitarios: un sistema de consulta de notas que dejó a cualquier estudiante ver las de otro con solo cambiar un número en la URL. El relato completo, con la solución correcta, está en la lectura disponible “El caso del sistema de notas filtrado”.
Debrief y cierre
La sesión empezó con una observación sin nombre y termina con ese mismo hallazgo ya nombrado: hay una parte de cualquier aplicación que el usuario ve y puede manipular, y hay otra parte que decide de verdad, que corre en un lugar que el usuario no controla. Esa distinción, cliente y servidor, frontend y backend, es la que vas a usar durante el resto de tu carrera para ubicar dónde revisar la seguridad de un sistema.
Lo que queda de esta clase está escrito y disponible sin fecha límite: la profundidad de las nueve preguntas de seguridad que no alcanzamos a desarrollar hoy, el caso completo del sistema de notas filtrado, y una lectura sobre la nube, el vocabulario de equipo, el flujo completo de una petición y el glosario de esta clase. Ninguna es obligatoria antes de la próxima sesión.
El laboratorio individual de esta clase te pide volver sobre el mismo sitio que tu grupo exploró hoy, esta vez para diseñar tú mismo un par de sus endpoints y pensar qué podría salir mal si nadie los protegiera bien.
Preguntas de reflexión
-
Abre las herramientas de desarrollador (
F12) en un servicio digital que uses a diario y que tu grupo no haya explorado en clase (tu banco, tu universidad, una red social, un servicio de streaming, una app de domicilios). Identifica al menos una petición cuya respuesta venga en formato JSON. Describe, sin copiar datos sensibles tuyos, qué información trae esa respuesta y explica si esa información debería depender del backend o si el sitio confía en que el frontend la calcule correctamente. -
Un desarrollador junior de tu equipo argumenta que, como el backend siempre revisa los permisos de cada petición, no vale la pena invertir tiempo en validar también los datos en el frontend, porque “esa validación nunca protege nada de verdad”. Toma una posición (de acuerdo o en desacuerdo), apoyándote en algo concreto que tu grupo haya observado en la pestaña Red durante la actividad de hoy, y formula después el argumento más fuerte que alguien con la posición contraria podría usar para refutarte.
-
Busca una noticia colombiana o latinoamericana reciente sobre una filtración de datos causada por una falla en una API o en el backend de una aplicación, no en el frontend. Incluye el enlace verificable a la noticia y explica, con tus propias palabras, en qué capa (frontend, backend o base de datos) ocurrió la falla según lo que la noticia describe.
-
La distinción entre una parte que el usuario ve y puede manipular, y una parte donde debe ocurrir la verificación real, también existe fuera del software. Piensa en un proceso físico o administrativo concreto (retirar dinero en un cajero, entrar a un edificio con tarjeta de acceso, radicar un documento en una entidad pública) y explica qué elemento de ese proceso cumple el papel del frontend y cuál cumple el papel del backend, y qué pasaría si la verificación real ocurriera solo en la parte visible.
-
Piensa de nuevo en el sitio que tu grupo exploró durante la actividad de esta clase (gov.co, bancolombia.com, eltiempo.com, unal.edu.co o compensar.com, según cuál le tocó a tu grupo). Revisa otra vez, en la pestaña Red, las peticiones que ese sitio hizo mientras cargaba y busca alguna cuyo dominio sea distinto al del sitio mismo (por ejemplo, un proveedor de analítica, de mapas, de pagos o de algún otro servicio externo que el sitio consulta). Si tu grupo no encontró ninguna, usa una que otro grupo haya reportado en la galería de hallazgos. A partir de esa petición real y específica, explica por qué ni “el frontend no es confiable” ni “el backend sí es confiable” alcanza para decidir qué tan seguro es depender de ese dominio externo, y qué tercera pregunta, distinta a las que ya viste sobre backend y base de datos, tendrías que agregar para evaluarlo.
Laboratorio práctico: Explorar APIs con las herramientas del navegador
Tiempo estimado: 60 minutos (trabajo individual fuera de la sesión) Requisitos: Navegador web (Chrome, Firefox o Edge) Nota: Solo analizas el sitio que tu grupo exploró en clase, u otro sitio público de tu elección, usando herramientas de desarrollo estándar del navegador. No se realizan ataques.
Objetivo
Volver sobre el sitio que tu grupo exploró en la actividad de hoy (o sobre otro sitio público si prefieres explorar algo distinto) para practicar con calma la lectura de una petición HTTP completa, y después diseñar y poner a prueba, con tus propias palabras, un par de endpoints reales de ese sitio.
Preparación: Herramientas de desarrollo del navegador
Todos los navegadores modernos incluyen herramientas para desarrolladores. Para abrirlas:
- Windows/Linux:
F12oCtrl+Shift+I - Mac:
Cmd+Option+I
Una vez abiertas, haz clic en la pestaña “Red” (o “Network” en inglés). Esta pestaña muestra todas las peticiones que hace el navegador.
Parte 1: Anatomía de una petición HTTP
Ejercicio 1.1: Anatomía de una petición HTTP
- Abre herramientas de desarrollo, pestaña Red, y navega a httpbin.org/get
- En la lista de peticiones, haz clic en la petición principal
- Explora las pestañas: Headers, Respuesta (o Response)
En la sección de Headers, identifica:
- La URL de la petición
- El método (GET, POST, etc.)
- El código de estado de la respuesta (200, 404, etc.)
- Los headers que envió tu navegador (User-Agent, Accept, etc.)
Responde:
- Pega aquí el valor exacto del header
User-Agentque tu navegador envió en la petición a httpbin.org/get, copiado directamente de la pestaña Headers. A partir de esa cadena específica (no de una respuesta general sobre qué es un User-Agent), indica qué versión de navegador y qué sistema operativo revela sobre tu propio equipo. - En la respuesta de httpbin.org, identifica un header que tu navegador haya enviado sin que tú lo hayas escrito en ningún formulario (por ejemplo
Accept-Language,Accept-EncodingoReferer). Cópialo tal cual aparece y explica qué información sobre ti o tu conexión revela ese header en particular. - En el cuerpo de la respuesta que te devolvió httpbin.org/get (pestaña Respuesta o Response, no la de Headers), busca el campo
origin. Copia el valor exacto que aparece ahí y explica qué representa ese dato concreto, y por qué el servidor pudo conocerlo sin que tú lo hayas escrito en ningún formulario ni header.
Ejercicio 1.2: Diferencia entre GET y POST
La API pública jsonplaceholder.typicode.com acepta peticiones POST de prueba. Desde la consola del navegador (pestaña Consola), pega y ejecuta este fragmento tal cual:
fetch('https://jsonplaceholder.typicode.com/posts', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({
titulo: 'Mi primer post',
contenido: 'Esto es una prueba',
usuarioId: 1
})
})
.then(respuesta => respuesta.json())
.then(datos => console.log(datos))Observa en la pestaña Red:
- La petición POST que se generó
- El cuerpo (body) de la petición, los datos que enviaste
- La respuesta del servidor
Responde:
- En la pestaña Red, localiza la petición POST que generaste hacia jsonplaceholder.typicode.com. Copia su URL exacta y escribe, al lado, cómo se vería esa misma URL si
titulo,contenidoyusuarioIdse hubieran enviado como parámetros GET en vez de en el cuerpo de la petición. Con las dos versiones lado a lado, explica qué diferencia observas en dónde queda el dato. - Copia y ejecuta este fragmento en la consola, tal cual, sin modificarlo:
fetch('https://jsonplaceholder.typicode.com/posts?titulo=Mi+primer+post&contenido=Esto+es+una+prueba')
.then(respuesta => respuesta.json())
.then(datos => console.log(datos))Nota: como titulo y contenido no existen en el esquema real de esta API, lo que verás en consola es simplemente la lista completa de posts sin filtrar; eso no importa para este ejercicio, porque lo que interesa es dónde quedó registrada la URL, no qué te devolvió. Observa en la pestaña Red y en el historial del navegador dónde queda esa URL completa. Si en vez de titulo y contenido esos parámetros fueran un usuario y una contraseña, explica con esa observación concreta por qué enviarlos por GET es un riesgo distinto a enviarlos por POST.
Parte 2: Diseña y pon a prueba los endpoints de tu sitio
Ejercicio 2.1: Diseño de endpoints a partir de tu sitio
Retoma el sitio que tu grupo exploró en la Actividad de esta clase. A partir de lo que observaron en la pestaña Red, propón cómo crees que están diseñados dos de sus endpoints reales (no inventados): para cada uno, escribe la URL aproximada, el método (GET, POST, etc.), qué información devuelve o recibe, y qué verificación de autorización debería tener para que un usuario no pudiera ver ni modificar datos que no le corresponden.
Ejercicio 2.2: Vulnerabilidades de diseño en esos mismos endpoints
Para cada uno de los dos endpoints que describiste en el Ejercicio 2.1, imagina que el backend no hiciera la verificación de autorización que propusiste. Describe, con un ejemplo concreto y anclado a lo que tu grupo observó, qué podría salir mal (qué dato de otra persona sería visible, o qué acción quedaría disponible sin permiso) y qué cambio de diseño lo evitaría.
Entregable
Crea un documento que incluya:
-
Análisis de la petición inspeccionada (Ejercicio 1.1)
- Captura de pantalla de la petición y la respuesta observadas
- Respuestas a las preguntas del ejercicio
-
Diseño de endpoints a partir del sitio explorado en clase (Ejercicio 2.1)
- Los dos endpoints propuestos, con método, datos y verificación de autorización
-
Vulnerabilidades de diseño en esos mismos endpoints (Ejercicio 2.2)
- Qué podría salir mal en cada uno y qué cambio de diseño lo evitaría
Criterios de evaluación
| Criterio | Puntos |
|---|---|
| Análisis de la petición inspeccionada (captura y respuestas) | 25 |
| Diseño de endpoints con control de acceso correcto | 40 |
| Identificación correcta de vulnerabilidades | 35 |
Reflexión
Después de completar el laboratorio:
- Antes de esta clase, ¿tenías idea de cuántas peticiones hace una aplicación web en segundo plano?
- ¿Qué impacto tiene en tu perspectiva saber que cualquier usuario puede ver las peticiones de red de su propio navegador?
- ¿Qué preguntas nuevas tienes para hacerle a tu equipo de desarrollo sobre la arquitectura de su proyecto?
Lectura disponible — Profundidad de las preguntas de seguridad por capa
La sesión desarrolló solo la pregunta más importante de cada capa. Estas son las que quedaron pendientes, con la consecuencia concreta de responderlas “no”.
Frontend
¿El frontend valida los datos del formulario? Está bien para la experiencia del usuario (avisar de inmediato que un campo quedó vacío, por ejemplo), pero recuerda que esa validación no es suficiente para seguridad: cualquiera puede desactivarla o enviar la petición directamente sin pasar por el formulario.
¿Cómo se manejan los errores? Si el frontend muestra información técnica interna cuando algo falla (el nombre exacto de una función, la ruta de un archivo en el servidor, el mensaje de error de la base de datos), le está regalando a un atacante un mapa de cómo está construido el sistema por dentro. Lo correcto es mostrar un mensaje genérico al usuario y guardar el detalle técnico solo en los registros internos del servidor.
Backend / API
¿Qué pasa si envío datos inesperados al endpoint? Un backend que no valida lo que recibe puede terminar procesando un tipo de dato distinto al que esperaba, o un valor fuera de rango que rompe una regla de negocio (una cantidad negativa en un pedido, por ejemplo).
¿Cómo se manejan las contraseñas? Deben guardarse como hash, nunca en texto plano, tal como viste en la clase 05. Un backend que guarda contraseñas legibles convierte cualquier filtración de la base de datos en una filtración de credenciales.
¿Qué información devuelve la API cuando hay un error? El mismo riesgo que en el frontend, pero del lado del servidor: un mensaje de error que revela detalles internos (versión del framework, estructura de la base de datos, rutas del sistema de archivos) es información gratis para quien está buscando por dónde entrar.
¿Hay límite en cuántas peticiones puede hacer un mismo usuario? Sin ese límite, alguien puede probar miles de contraseñas por segundo contra el endpoint de login (fuerza bruta) o saturar el servidor con peticiones hasta dejarlo sin respuesta (denegación de servicio).
Base de datos
¿Los datos sensibles están cifrados? El cifrado en tránsito (HTTPS) protege el dato mientras viaja; el cifrado en reposo protege el dato mientras está guardado. Son controles distintos, y muchos sistemas solo implementan el primero.
¿Cómo se hacen las consultas? Si se arman pegando texto en vez de usar consultas parametrizadas, el sistema queda abierto a la inyección SQL que practicaste en el laboratorio de la clase 05.
¿Hay algún panel de administración? Y si lo hay, ¿quién puede acceder? Un panel de administración expuesto a internet, con la contraseña de fábrica sin cambiar, es una de las formas más comunes de configuración insegura.
Lectura disponible — El caso del sistema de notas filtrado
El siguiente caso es ficticio, pero está construido sobre un patrón que se repite cada semestre en proyectos universitarios reales. Un equipo de estudiantes de una universidad colombiana construyó, para su propio proyecto de grado, una plataforma donde cada estudiante podía consultar sus notas ingresando a:
GET /api/notas/estudiante/12345
Cuando un estudiante iniciaba sesión y consultaba sus notas, el frontend hacía una petición con su número de matrícula, y la aplicación devolvía las notas correctamente.
El problema: el backend no verificaba que el número de matrícula en la URL correspondiera al usuario autenticado. Cualquier estudiante podía cambiar 12345 por 12346 en la URL y ver las notas de otro compañero.
Esta es exactamente la vulnerabilidad de referencia insegura a objetos (IDOR) del OWASP Top 10, la misma familia que viste en la clase 05, y es uno de los errores más comunes en proyectos académicos.
La solución correcta:
GET /api/mis-notas ← sin número de matrícula en la URL
El backend obtiene la identidad del usuario del token de autenticación, no de la URL, y devuelve solo sus propias notas. El usuario no puede pedir notas de otro porque no tiene forma de pedirlas por nombre: el backend sabe quién eres por el token.
Lectura disponible — La nube, el vocabulario de equipo, el flujo completo de una petición y el glosario
La nube
Cuando alguien dice que una aplicación “está en la nube”, se refiere simplemente a que el servidor que responde tus peticiones es una máquina alquilada, por horas o por uso, a una empresa que se dedica a tener miles de servidores disponibles para que otros los usen, en vez de una máquina que la propia empresa compró y guarda en un cuarto propio. Amazon, con Amazon Web Services, y Google, con Google Cloud, son dos de los proveedores más grandes de este servicio. Para tu equipo de proyecto esto tiene una consecuencia práctica: lo más probable es que su aplicación termine corriendo en un servidor alquilado que cualquiera del grupo puede configurar mal sin que se note, hasta que alguien externo lo aprovecha.
La responsabilidad de proteger ese servidor queda repartida entre dos partes. El proveedor de la nube se encarga de la infraestructura física y de la red: los servidores, los centros de datos, la conexión a internet. Quien construye la aplicación (tu equipo) sigue siendo responsable de configurar bien los permisos, el código y los datos que ahí se guardan. Ningún proveedor de nube protege a un equipo que deja una base de datos abierta a internet por descuido; esa parte del trabajo nunca se delega.
Vocabulario para trabajar con tu equipo
Cuando hables con tus compañeros de Ingeniería de Software e IA, estos términos facilitarán la comunicación:
| Término | Qué significa | Para qué lo usas |
|---|---|---|
| Endpoint | Una URL específica de la API | ”¿El endpoint de login tiene límite de intentos?” |
| Autenticación | Verificar quién eres | ”¿Cómo se implementa la autenticación?” |
| Autorización | Verificar qué puedes hacer | ”¿El endpoint verifica autorización?” |
| Token / JWT | Credencial que prueba tu identidad | ”¿Dónde se guarda el token en el frontend?” |
| HTTPS | HTTP con cifrado | ”¿Todo el tráfico usa HTTPS?” |
| Logs | Registro de actividad del sistema | ”¿Qué eventos quedan registrados en los logs?” |
| Validación de entrada | Verificar que los datos son correctos | ”¿El backend valida todos los campos antes de procesarlos?” |
Cómo fluye una petición web, paso a paso completo
Juntando todo lo anterior, así es como funciona algo tan simple como iniciar sesión en una aplicación:
1. Escribes tu usuario y contraseña en el formulario del frontend
[Navegador] → formulario HTML con campos de texto
2. Haces clic en "Iniciar sesión"
[JavaScript] → prepara una petición HTTP POST a /api/login
Cuerpo de la petición: { "usuario": "ana@ejemplo.com", "contraseña": "..." }
3. La petición viaja por Internet hasta el servidor backend
[Internet] → protocolo HTTPS (cifrado para que nadie en el medio pueda leerla)
4. El backend recibe la petición y la procesa
[Backend] → verifica que el usuario existe en la base de datos
[Backend] → comprueba que la contraseña (su hash) coincide
[Backend] → crea una sesión o genera un token JWT
5. El backend responde
[Backend] → { "exito": true, "token": "eyJ0eXAiOi..." }
6. El frontend recibe la respuesta y actúa
[JavaScript] → guarda el token, redirige al usuario a la página principal
Cada uno de estos pasos puede fallar de seguridad si no se implementa correctamente. El punto 3 es donde importa HTTPS. El punto 4 es donde importa el hash de contraseñas, que trabajaste en la clase 05. El punto 5 es donde importa el manejo seguro de tokens, que trabajaste en la clase 06.
Conceptos clave
| Término | Definición |
|---|---|
| Cliente-servidor | Modelo donde un programa pide (cliente) y otro responde (servidor) |
| Frontend | La parte de la aplicación que corre en el navegador del usuario |
| Backend | La parte de la aplicación que corre en el servidor, con la lógica del sistema |
| API | Conjunto de endpoints que definen cómo el frontend y el backend se comunican |
| Base de datos | Sistema que almacena y organiza los datos de forma persistente |
| JSON | Formato de texto estructurado usado para intercambiar datos entre frontend y backend |
| HTTPS | HTTP con cifrado TLS, protege los datos en tránsito |
| Endpoint | Una URL específica de la API que realiza una función concreta |
Navegación: ← Anterior | Inicio | Siguiente: Criptografía aplicada →