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

Tu rol en el equipo de proyecto

En el proyecto de este semestre trabajas con estudiantes de Ingeniería de Software y/o de Inteligencia Artificial. Ellos construirán la aplicación; tú la analizarás desde la perspectiva de seguridad. Pero para hacer ese trabajo bien, necesitas entender qué están construyendo.

Esta clase te da el vocabulario y los conceptos fundamentales para:

Entender las decisiones de arquitectura que toman tus compañeros
Identificar en qué partes del sistema pueden surgir los problemas de seguridad que ya estudiaste (OWASP, STRIDE, control de acceso)
Hacer las preguntas correctas durante el diseño, antes de que sea costoso cambiar algo

La idea central: cliente y servidor

Toda aplicación web funciona con un modelo básico: 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 web, una app de celular, incluso otro programa en un servidor. El servidor es el programa que espera esas peticiones y las responde.

Esta interacción pasa miles de veces por segundo en cada aplicación que usas. Cada vez que abres Instagram, buscas algo en Google, o haces clic en un botón, estás generando peticiones que van a un servidor y regresan con respuestas.

¿Por qué importa para seguridad? Cada petición que sale del cliente es una oportunidad para que un atacante interfiera. Cada respuesta del servidor puede contener datos que deben protegerse. El modelo cliente-servidor es la base de toda la seguridad web.

Las tres partes de una aplicación web

La mayoría de aplicaciones web modernas tienen tres componentes principales:

┌──────────────────────────────────────────────────────────┐
│  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)                   │
└──────────────────────────────────────────────────────────┘

El frontend: lo que el usuario ve

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 en tres tecnologías:

HTML: La estructura de la página (qué hay y en qué orden)
CSS: El aspecto visual (colores, tamaños, disposición)
JavaScript: El comportamiento interactivo (qué pasa cuando haces clic)

El código del frontend corre en el navegador del usuario. Esto tiene una implicación de seguridad fundamental: cualquier usuario puede verlo, modificarlo y manipularlo. Nunca puedes confiar en que el frontend proteja algo — toda verificación real debe ocurrir en el backend.

El backend: donde ocurre la lógica

El backend es el programa que corre en un servidor, invisible para el usuario. Es donde ocurren las cosas importantes: verificar si una contraseña es correcta, calcular el precio de un pedido, decidir qué información puede ver cada usuario.

El backend recibe peticiones del frontend, las procesa según las reglas del sistema, consulta la base de datos si es necesario, y envía la respuesta de vuelta.

Los ingenieros de software de tu equipo usarán lenguajes como Python (con frameworks como Django o FastAPI), JavaScript (con Node.js), Java, o Go para escribir el backend.

¿Por qué es la parte más crítica para seguridad? El backend es la última línea de defensa. Si el backend no verifica permisos, no importa que el frontend “oculte” un botón — un atacante puede enviar la petición directamente. Si el backend no valida los datos, puede ser vulnerable a inyección SQL. Todas las vulnerabilidades del OWASP Top 10 que estudiaste en la clase 5 viven aquí.

La base de datos: donde viven los datos

La base de datos es el sistema que guarda y organiza la información de forma persistente. Cuando apagas el servidor, los datos siguen ahí; cuando lo vuelves a encender, están donde los dejaste.

Existen dos grandes tipos de bases de datos:

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. La más importante que conocer: las consultas a estas bases de datos se escriben en SQL, y de ahí viene la vulnerabilidad de SQL Injection que practicaste en el laboratorio de la clase 5.

Cómo se comunican las partes: las APIs

Aquí está el concepto más importante de esta clase para la seguridad.

API significa 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 así: cuando vas a un restaurante, no entras a la cocina a preparar tu comida. Le dices al mesero lo que quieres (siguiendo el “protocolo” del menú), el mesero se lo dice 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
La petición puede incluir datos (por ejemplo, en un formulario o en el cuerpo de la solicitud)
El backend procesa la petición y devuelve una respuesta — usualmente en formato JSON

¿Qué es JSON?

JSON es el formato de datos más usado para comunicar frontend y backend. Se parece a esto:

{
  "usuario": {
    "id": 42,
    "nombre": "Ana García",
    "email": "ana@ejemplo.com",
    "rol": "estudiante"
  }
}

Es texto estructurado que tanto el frontend como el backend pueden leer y generar fácilmente. Si alguna vez inspeccionas el tráfico de red de una aplicación web (como hiciste en la clase anterior), verás que la mayor parte es JSON yendo y viniendo.

Endpoints: las puertas de la API

Cada función de la API tiene una URL específica llamada endpoint. Por ejemplo:

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 un atacante puede hacer, lo hace a través de la API. Las vulnerabilidades de IDOR que estudiaste en la clase 5 — como cambiar el número en la URL para ver datos de otro usuario — ocurren exactamente aquí. El control de acceso que estudiaste en la clase 6 se implementa aquí.

Cómo fluye una petición web

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 (clase 5). El punto 5 es donde importa el manejo seguro de tokens (clase 6).

La arquitectura de tu proyecto

Para proyectos académicos como el tuyo, la arquitectura típica es:

┌────────────────────────────────────────────────────────────────┐
│                         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 aquí?

Las preguntas de seguridad correctas por capa

Cuando diseñes o revises la arquitectura de tu proyecto, estas son las preguntas que debes hacerle al equipo:

Sobre el frontend

¿El frontend valida los datos del formulario? (Está bien para experiencia de usuario, pero recuerda: no es suficiente para seguridad)
¿El frontend almacena información sensible en el navegador? (Tokens de sesión, datos del usuario)
¿Cómo se manejan los errores? ¿Se muestra información técnica interna al usuario?

Sobre la API / backend

¿Cada endpoint verifica que el usuario tiene permiso para hacer lo que está pidiendo? (La pregunta más importante — esto es control de acceso de la clase 6)
¿Qué pasa si envío datos inesperados al endpoint? ¿El backend los valida?
¿Cómo se manejan las contraseñas? ¿Se guardan como hash?
¿Qué información devuelve la API cuando hay un error? ¿Revela detalles internos?
¿Hay límite en cuántas peticiones puede hacer un mismo usuario? (Para prevenir fuerza bruta y DoS)

Sobre la base de datos

¿Quién tiene acceso a la base de datos? ¿Solo el backend, o también hay acceso externo?
¿Los datos sensibles están cifrados?
¿Cómo se hacen las consultas? ¿Se usan consultas parametrizadas (para prevenir SQL injection)?
¿Hay algún panel de administración? ¿Quién puede acceder?

Caso de estudio: el proyecto universitario que se filtró

Un equipo de estudiantes construyó una plataforma para consultar notas. Así era su API:

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. 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 IDOR (Insecure Direct Object Reference) del OWASP Top 10 — y es el error más común 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.

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?”

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

Ponte a prueba

Modelo cliente-servidor: Cuando abres la aplicación de tu banco en el celular y revisas tu saldo, ¿qué es el cliente y qué es el servidor? ¿Qué petición hace el cliente? ¿Qué responde el servidor?
Identificar la falla: 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?
Frontend vs backend: Un compañero propone validar los formularios solo en el frontend (en JavaScript) para “no sobrecargar el servidor”. ¿Qué le responderías desde la perspectiva de seguridad?

Laboratorio práctico: Explorar APIs con las herramientas del navegador

Tiempo estimado: 90 minutos Requisitos: Navegador web (Chrome, Firefox o Edge) Nota: Solo analizamos sitios públicos usando herramientas de desarrollo estándar del navegador. No se realizan ataques.

Objetivo

Ver cómo funciona una API real usando las herramientas que ya tienes instaladas. Entender qué información viaja entre el frontend y el backend, y cómo conectar eso con los conceptos de seguridad que has estudiado.

Preparación: Herramientas de desarrollo del navegador

Todos los navegadores modernos incluyen herramientas para desarrolladores. Para abrirlas:

Windows/Linux: F12 o Ctrl+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: Observar peticiones de red (30 min)

Ejercicio 1.1: Ver una API en acción

Abre las herramientas de desarrollo y ve a la pestaña Red
Navega a jsonplaceholder.typicode.com
En la pestaña Red, busca peticiones de tipo “fetch” o “XHR”
Ahora abre una nueva pestaña y ve directamente a: https://jsonplaceholder.typicode.com/users

Verás directamente la respuesta JSON de una API real. Esta API simula un sistema con usuarios, posts y comentarios.

Explora los endpoints:

https://jsonplaceholder.typicode.com/users — Lista de usuarios
https://jsonplaceholder.typicode.com/users/1 — Un usuario específico
https://jsonplaceholder.typicode.com/users/1/posts — Posts del usuario 1
https://jsonplaceholder.typicode.com/posts/1/comments — Comentarios de un post

Responde:

¿Qué información contiene cada usuario? ¿Qué datos serían sensibles si esto fuera una aplicación real?
¿Puedes ver los datos de cualquier usuario cambiando el número en la URL?
¿Qué verificación de seguridad debería tener esta API para ser usada en producción?

Ejercicio 1.2: Analizar peticiones de una aplicación real

Abre las herramientas de desarrollo (F12) y ve a la pestaña Red
Navega a www.reddit.com
Observa las peticiones que aparecen en la pestaña Red

Filtra por tipo: busca las peticiones de tipo fetch o las que van a URLs que contengan /api/ o .json.

Responde:

¿Cuántas peticiones hace Reddit al cargar la página?
¿Puedes identificar alguna petición que claramente traiga datos de posts o comentarios?
¿Qué formato tienen los datos de las respuestas? ¿Son JSON?

Parte 2: Inspeccionar una petición específica (20 min)

Ejercicio 2.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:

¿Qué información revela el header User-Agent sobre tu navegador?
¿Por qué podría un atacante encontrar útil conocer el software exacto que usa un servidor?
El servidor te devolvió información sobre tu propia petición. ¿Qué datos de tu navegador quedaron expuestos?

Ejercicio 2.2: Diferencia entre GET y POST

La API de JSONPlaceholder también acepta peticiones POST. Desde la consola del navegador (pestaña Consola), ejecuta:

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:

¿Qué diferencia hay entre enviar datos en una URL (GET) vs en el cuerpo de la petición (POST)?
Si un formulario de login enviara la contraseña como parámetro GET (en la URL), ¿qué problema de seguridad tendría? (Pista: piensa en quién puede ver las URLs)

Parte 3: Analizar la arquitectura de una API desde la perspectiva de seguridad (40 min)

Ejercicio 3.1: Diseño de API para tu proyecto

Imagina que tu equipo va a construir una aplicación de gestión de tareas académicas. Los estudiantes pueden crear tareas, ver sus propias tareas, y marcarlas como completadas. Los profesores pueden ver las tareas de todos sus estudiantes.

Diseña los endpoints de la API completando la siguiente tabla:

Endpoint	Método	Qué hace	¿Quién puede usarlo?
`/api/tareas`	GET	Listar todas mis tareas	Estudiante autenticado
`/api/tareas`	POST	Crear una nueva tarea
`/api/tareas/{id}`	GET	Ver una tarea específica
`/api/tareas/{id}`	PUT	Editar una tarea
`/api/tareas/{id}`	DELETE	Borrar una tarea
`/api/estudiantes/{id}/tareas`	GET	Ver tareas de un estudiante

Para cada endpoint, responde:

¿Qué verificación de autenticación necesita? (¿Debe el usuario estar autenticado?)
¿Qué verificación de autorización necesita? (¿Debe verificarse que el usuario tiene permiso para ese recurso específico?)
¿Qué datos sensibles maneja?

Ejercicio 3.2: Identificar vulnerabilidades de diseño

Analiza el siguiente diseño de API propuesto por un equipo de software y encuentra los problemas de seguridad:

Diseño propuesto:

GET /api/calificaciones?estudiante=12345    ← busca calificaciones por número de matrícula
GET /api/usuarios?admin=true               ← lista todos los administradores
POST /api/login                            ← sin límite de intentos
GET /api/exportar-datos?formato=csv        ← exporta todos los datos del sistema
DELETE /api/usuarios/{id}                  ← borra un usuario

Responde para cada endpoint:

¿Qué vulnerabilidad o riesgo identificas?
¿Qué cambio de diseño propondrías?

Entregable

Crea un documento que incluya:

Análisis de APIs exploradas (Ejercicios 1.1 y 1.2)
- Capturas de pantalla de las peticiones y respuestas observadas
- Respuestas a las preguntas de cada ejercicio
Diseño de API para la aplicación de tareas (Ejercicio 3.1)
- Tabla de endpoints completa con permisos definidos
- Justificación de las decisiones de control de acceso
Análisis de vulnerabilidades (Ejercicio 3.2)
- Problema identificado en cada endpoint del diseño propuesto
- Corrección propuesta con justificación
Auditoría de tu proyecto (Ejercicio 3.3)
- Checklist completo con respuestas y plan de acción para los puntos que fallen

Criterios de evaluación

Criterio	Puntos
Análisis de APIs exploradas (capturas y respuestas)	20
Diseño de endpoints con control de acceso correcto	30
Identificación correcta de vulnerabilidades	25
Checklist de auditoría del proyecto propio	25

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?

Navegación: ← Anterior | Inicio | Siguiente: Evaluación →

ICIB

Explorador

08 - Panorama tecnológico

Panorama tecnológico: Cómo funciona una aplicación web

Tu rol en el equipo de proyecto

La idea central: cliente y servidor

Las tres partes de una aplicación web

El frontend: lo que el usuario ve

El backend: donde ocurre la lógica

La base de datos: donde viven los datos

Cómo se comunican las partes: las APIs

¿Qué es JSON?

Endpoints: las puertas de la API

Cómo fluye una petición web

La arquitectura de tu proyecto

Las preguntas de seguridad correctas por capa

Sobre el frontend

Sobre la API / backend

Sobre la base de datos

Caso de estudio: el proyecto universitario que se filtró

Vocabulario para trabajar con tu equipo

Conceptos clave

Ponte a prueba

Laboratorio práctico: Explorar APIs con las herramientas del navegador

Objetivo

Preparación: Herramientas de desarrollo del navegador

Parte 1: Observar peticiones de red (30 min)

Ejercicio 1.1: Ver una API en acción

Ejercicio 1.2: Analizar peticiones de una aplicación real

Parte 2: Inspeccionar una petición específica (20 min)

Ejercicio 2.1: Anatomía de una petición HTTP

Ejercicio 2.2: Diferencia entre GET y POST

Parte 3: Analizar la arquitectura de una API desde la perspectiva de seguridad (40 min)

Ejercicio 3.1: Diseño de API para tu proyecto

Ejercicio 3.2: Identificar vulnerabilidades de diseño

Entregable

Criterios de evaluación

Reflexión

Vista Gráfica

Tabla de Contenidos

Retroenlaces