DEV Community: Gabriela Estefania Cohaila Alvarado

Diseño e implementación de una arquitectura web para una red social universitaria

Gabriela Estefania Cohaila Alvarado — Mon, 05 Oct 2026 02:33:48 +0000

Autora: Gabriela Estefania Cohaila Alvarado

Código: 2022075746

Proyecto: CampusConecta

Resumen

Este artículo describe el diseño y la implementación de CampusConecta, una plataforma web para la interacción entre estudiantes, docentes y personal universitario. La solución se construyó con React y TypeScript en el cliente, ASP.NET Core Web API en el servidor y PostgreSQL como base de datos. El trabajo se enfoca en las decisiones de arquitectura, el modelo relacional, la API REST, la autenticación mediante JSON Web Token, la validación de datos y la persistencia. La verificación incluyó seis pruebas automáticas de integración, compilación del frontend y un flujo HTTP ejecutado contra PostgreSQL real. En ese flujo se creó una publicación, un comentario y una reacción; posteriormente, la búsqueda y el panel personal recuperaron los cambios persistidos. Las seis pruebas automáticas aprobaron. Una muestra exploratoria de veinte consultas locales al feed obtuvo una media de 5.40 ms y un percentil 95 de 9.58 ms. Estas cifras corresponden al entorno de desarrollo y no constituyen una prueba de carga. El resultado es una plataforma funcional, reproducible y preparada para evolucionar hacia un escenario institucional.

Palabras clave: arquitectura web, ASP.NET Core, API REST, JWT, PostgreSQL, React, red social universitaria.

Introducción

Un sitio de red social permite construir perfiles, relacionar participantes e intercambiar contenido dentro de un sistema delimitado. Boyd y Ellison definen estos elementos como rasgos centrales de las redes sociales en línea [1]. En una universidad, la misma idea requiere adaptar la interacción a una comunidad con estudiantes, docentes y personal, así como proteger las operaciones que cambian contenido o identidad.

CampusConecta se desarrolló como una aplicación web completa y ejecutable. No se planteó como una interfaz estática. Cada interacción visible se conecta con una ruta de la API y con una operación persistente. El sistema cubre registro, inicio de sesión, perfiles, publicaciones, comentarios, reacciones, comunidades, membresías, búsqueda y un panel personal. También incorpora respuestas de error y documentación Swagger para inspeccionar los contratos HTTP.

El reto principal consistió en integrar estas funciones sin concentrar la lógica en la interfaz ni permitir que el cliente decidiera permisos sensibles. Por ello, el proyecto separa presentación, servicios y persistencia. Esta organización facilita probar el backend de forma aislada, usar otro cliente en el futuro y mantener las reglas de autorización cerca de los datos que protegen.

Objetivo

Diseñar e implementar una arquitectura web para una red social universitaria que incluya API REST, autenticación JWT, persistencia PostgreSQL, interfaz React y mecanismos básicos de validación y manejo de errores.

El alcance implementado incluye:

Registro e inicio de sesión.
Consulta y edición del perfil propio.
Feed, creación y eliminación autorizada de publicaciones.
Comentarios y reacciones.
Creación, consulta y administración básica de comunidades.
Unión y salida de comunidades.
Búsqueda de usuarios, publicaciones y comunidades.
Panel personal con métricas y actividad reciente.
Swagger/OpenAPI, endpoint de salud, migraciones y pruebas.

No se implementaron mensajería privada, recuperación de contraseñas, carga de archivos, notificaciones en tiempo real ni autenticación federada. Declarar estos límites evita atribuir al sistema capacidades que no fueron desarrolladas.

Arquitectura de la solución

CampusConecta sigue una arquitectura de tres capas desplegables.

Capa	Tecnología	Responsabilidad
Presentación	React 19, TypeScript y Vite	Formularios, navegación, estados de carga, visualización del feed y mensajes al usuario.
Servicios	ASP.NET Core 8 Web API	Endpoints REST, contratos, validaciones, autenticación, autorización y manejo de errores.
Persistencia	Entity Framework Core 8, Npgsql y PostgreSQL	Modelo relacional, migraciones, consultas e integridad de los datos.
Operación	Swagger/OpenAPI y Docker Compose	Exploración de la API, ejecución local y base de datos reproducible.

La aplicación React consume respuestas JSON a través de una capa de acceso centralizada. Esa capa adjunta el token Bearer a las solicitudes autenticadas y traduce los errores de la API en mensajes que el usuario puede comprender. La interfaz contiene vistas para acceso, feed, comunidades, búsqueda, panel y perfil.

La API agrupa responsabilidades por recurso. AuthController registra y autentica cuentas. UsersController consulta y actualiza perfiles. PostsController resuelve feed, publicaciones, comentarios y reacciones. CommunitiesController administra comunidades y membresías. SearchController combina resultados de diferentes recursos, y DashboardController calcula los indicadores personales. Un middleware global transforma excepciones conocidas en respuestas HTTP consistentes y evita devolver trazas internas.

Modelo de datos y persistencia

El esquema relacional contiene seis entidades principales.

Entidad	Propósito y restricciones relevantes
`Users`	Conserva identidad, rol, perfil y hash de contraseña. El correo y el nombre de usuario son únicos.
`Communities`	Representa cada comunidad, su descripción, creador y estado.
`CommunityMembers`	Materializa la relación entre usuarios y comunidades; evita duplicar la membresía.
`Posts`	Guarda contenido, fecha, autor y comunidad opcional.
`Comments`	Relaciona un comentario con una publicación y su autor.
`Reactions`	Registra una reacción por combinación de usuario y publicación.

Las claves foráneas garantizan que una publicación no exista sin autor y que un comentario no exista sin publicación. Las restricciones únicas protegen correos, nombres de usuario, nombres de comunidad, membresías y reacciones repetidas. PostgreSQL documenta las restricciones como reglas que rechazan escrituras incompatibles con el esquema [2]. En CampusConecta complementan las validaciones de la API, no las sustituyen.

Entity Framework Core genera y aplica la migración InitialCreate. Durante la validación se usó una instancia PostgreSQL real. La migración se aplicó correctamente y, tras el flujo de aceptación, se verificaron 3 usuarios, 3 publicaciones, 2 comentarios, 3 reacciones, 1 comunidad y 3 membresías. La configuración de entrega incorpora Docker Compose con PostgreSQL 16 para que el entorno pueda reconstruirse sin depender de la instancia usada durante las pruebas.

Diseño de la API REST

Las rutas describen recursos y utilizan verbos HTTP de acuerdo con la operación. POST registra recursos; GET consulta; PUT actualiza perfil o reacción; y DELETE elimina contenido propio o abandona una comunidad. El contrato se expone en Swagger, que permite examinar esquemas y probar endpoints durante el desarrollo. La especificación OpenAPI define un formato estándar para describir este tipo de interfaces [3].

Área	Operaciones representativas	Protección
Autenticación	`POST /api/auth/register`, `POST /api/auth/login`	Pública
Perfil	`GET /api/users/me`, `PUT /api/users/me`	JWT
Publicaciones	`GET/POST /api/posts`, comentarios y reacciones	JWT; propiedad para eliminar
Comunidades	`GET/POST /api/communities`, `join`, `leave`	JWT; reglas de membresía
Consulta	`GET /api/search`, `GET /api/dashboard`	JWT
Operación	`GET /health`, `/swagger`	Pública en desarrollo

La API usa códigos de estado para distinguir condiciones. Una entrada inválida devuelve 400; una solicitud sin sesión devuelve 401; una acción sobre un recurso ajeno devuelve 403; y un recurso inexistente devuelve 404. Este comportamiento permite que el frontend informe el problema sin interpretar mensajes técnicos del servidor.

Autenticación y autorización

El registro valida el formato del correo, la longitud de los campos y la fortaleza mínima de la contraseña. La contraseña no se persiste como texto legible. ASP.NET Core PasswordHasher<AppUser> crea un hash con salt y parámetros de trabajo. OWASP recomienda almacenar contraseñas con funciones lentas y adaptativas, y nunca en texto plano [4].

Después de un inicio de sesión válido, la API genera un JWT firmado con identificador, correo, nombre de usuario y rol. RFC 7519 describe JWT como una representación compacta de claims intercambiable entre partes [5]. El middleware valida la firma, el emisor, la audiencia y el vencimiento antes de crear la identidad de la solicitud. Los controladores obtienen el identificador desde los claims y verifican propiedad o membresía antes de modificar un recurso.

La prueba automática de rutas protegidas solicitó el panel personal sin token y recibió 401. Las operaciones de eliminación también se restringen en servidor. Por ejemplo, ocultar un botón en React no basta: la API revisa que el autor de la solicitud sea el propietario del contenido.

La clave JWT y las credenciales de base de datos incluidas en la configuración son únicamente valores de desarrollo local. Antes de desplegar se deben reemplazar mediante variables de entorno o un gestor de secretos, habilitar HTTPS y reducir la exposición de Swagger. Para una universidad, la siguiente mejora prioritaria es incorporar OpenID Connect con la identidad institucional. Microsoft indica que los tokens propios son apropiados para sistemas cerrados y pruebas, pero no reemplazan una autoridad de identidad administrada [6].

Implementación del frontend

La interfaz se construyó con React, TypeScript y Vite. React organiza la experiencia mediante componentes que combinan estado y representación [7]. En CampusConecta, la vista principal recupera el feed y permite crear publicaciones; cada tarjeta muestra autor, fecha, comunidad, reacciones y comentarios. Las vistas de comunidad indican miembros y estado de unión. La búsqueda muestra resultados por tipo y el panel personal resume actividad reciente.

Los formularios controlan datos incompletos antes de enviar la solicitud, pero la validación definitiva está en la API. Las respuestas de error se muestran como mensajes de interfaz. Esta combinación evita solicitudes triviales innecesarias sin confiar en el navegador para decisiones de seguridad.

Verificación técnica

La verificación combinó pruebas automáticas, revisión del frontend y ejecución integral.

Verificación	Resultado
`dotnet test CampusConecta.sln --configuration Release`	6 pruebas aprobadas, 0 fallidas, 0 omitidas.
`npm run lint`	Aprobado sin advertencias.
`npm run build`	Build de producción correcto.
PostgreSQL real	Migración aplicada y flujo de escritura/lectura confirmado.
Interfaz	Ocho capturas reales de los recorridos principales.

Las pruebas de API cubrieron salud, hash de una cuenta inicial, rechazo de contraseña débil, registro con JWT, feed, publicaciones, comentarios, reacciones, panel, comunidades, búsqueda, perfil y rechazo de acceso sin JWT. La prueba integral creó una publicación, un comentario y una reacción mediante HTTP; la búsqueda recuperó la publicación y el panel actualizó sus indicadores.

Se realizaron veinte solicitudes consecutivas al feed en el mismo equipo que alojaba la API. La media fue 5.40 ms, la mediana 4.73 ms, el percentil 95 9.58 ms, el mínimo 3.27 ms y el máximo 11.21 ms. La muestra permite detectar regresiones locales; no mide concurrencia, red pública ni capacidad productiva.

Discusión

La arquitectura logró que cada requisito tuviera una representación visible, un endpoint y una regla de persistencia. Separar React de ASP.NET Core permitió validar el backend sin navegador y después confirmar la integración completa. PostgreSQL preservó las relaciones entre usuarios, contenido y comunidades mediante restricciones explícitas.

Persisten límites propios del alcance académico. El feed no usa caché ni cursores; la búsqueda no incorpora índices especializados; las imágenes se manejan como URL y no existe almacenamiento administrado. Tampoco se realizaron pruebas de carga, auditoría externa de seguridad o evaluación con usuarios. Estas limitaciones son puntos de evolución, no resultados omitidos.

Conclusiones

CampusConecta demuestra una implementación funcional de red social universitaria con arquitectura separada, API REST, JWT, PostgreSQL, migraciones y Swagger. Las acciones principales modificaron una base real y sus resultados aparecieron en feed, búsqueda y panel. Las seis pruebas aprobadas y la compilación del frontend aportan evidencia de corrección en el alcance desarrollado.

La siguiente etapa debe incorporar autenticación institucional, secretos externos, HTTPS obligatorio, auditoría de acciones, reportes de contenido, pruebas de carga y accesibilidad asistida. Estas mejoras pueden añadirse sobre la estructura actual sin reescribir las capas principales.

Referencias

boyd, d. m., y Ellison, N. B. (2007). Social Network Sites: Definition, History, and Scholarship. Journal of Computer-Mediated Communication, 13(1), 210–230. https://doi.org/10.1111/j.1083-6101.2007.00393.x
PostgreSQL Global Development Group. (2026). PostgreSQL documentation: Constraints. https://www.postgresql.org/docs/current/ddl-constraints.html
OpenAPI Initiative. (2026). OpenAPI Specification. https://spec.openapis.org/oas/
OWASP Foundation. (2026). Password Storage Cheat Sheet. https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html
Jones, M., Bradley, J., y Sakimura, N. (2015). JSON Web Token (JWT), RFC 7519. Internet Engineering Task Force. https://www.rfc-editor.org/rfc/rfc7519
Microsoft. (2026). Configure JWT bearer authentication in ASP.NET Core. https://learn.microsoft.com/aspnet/core/security/authentication/configure-jwt-bearer-authentication
React Team. (2026). React documentation. https://react.dev/learn

Análisis de vulnerabilidades y despliegue automatizado de una app con Bearer CLI y ESLint

Gabriela Estefania Cohaila Alvarado — Sun, 04 Oct 2026 10:05:34 +0000

Autores del artículo:
Gabriela Estefania Cohaila Alvarado (2022075746)

Integrantes:
Gabriela Estefania Cohaila Alvarado (2022075746)
Jhony Vargas Luque (2022075754)

En este proyecto construimos Notas Seguras, una aplicación de tareas en JavaScript, para estudiar cómo detectar y corregir problemas de seguridad antes de publicar una nueva versión. Comparamos implementaciones educativas inseguras con el código corregido mediante Bearer CLI y ESLint con reglas de seguridad, y conectamos los controles con un despliegue automatizado en GitHub Pages.

Los resultados fueron concretos: Bearer reportó dos hallazgos altos en los componentes vulnerables; ESLint señaló esos mismos puntos y un uso adicional de eval. Después de corregir el código, ambos analizadores terminaron sin hallazgos en la aplicación publicable y las cinco pruebas de regresión pasaron. En este artículo presentamos conjuntamente los hallazgos, las correcciones y la automatización.

Código y aplicación

La aplicación y el alcance del experimento

Notas Seguras permite crear tareas con título, descripción, prioridad y minutos estimados; también buscar, filtrar, completar y eliminar tareas. Está desarrollada con HTML, CSS y JavaScript. Guarda la información mediante localStorage en el navegador, sin cuentas, sincronización ni backend de negocio. GitHub Pages sirve los archivos estáticos de la aplicación por HTTPS.

El repositorio separa dos alcances. examples/vulnerable/ conserva las implementaciones inseguras de tres funciones para realizar la comparación. app/ contiene la aplicación completa con esas funciones corregidas. La baseline es un ejemplo educativo de componentes, no una aplicación anterior que se haya publicado. El escaneo inicial cubre esos componentes; el análisis final cubre toda la aplicación publicable.

Selección de herramientas distintas a los laboratorios

Revisamos las cuatro guías de laboratorio compartidas: lab01 utiliza SonarQube/SonarCloud; lab02, Snyk; lab03, Semgrep; y lab04, tfsec y SonarCloud. Para este trabajo elegimos Bearer CLI 2.1.1 y ESLint 10.12.0 con eslint-plugin-no-unsanitized 4.1.5, que no aparecen en esas cuatro guías.

Bearer figura en el catálogo de analizadores de código de OWASP. También consultamos el directorio de analizadores de NIST como referencia. La inclusión en un catálogo no certifica la seguridad del proyecto ni implica un aval de sus resultados.

ESLint es un analizador configurable. En nuestro caso, el plugin de Mozilla prohíbe operaciones de inserción HTML inseguras y las reglas de ESLint restringen evaluación dinámica de JavaScript. Lo usamos como control complementario de patrones de seguridad, sin atribuirle una auditoría general de todos los riesgos de la aplicación. Esta configuración no requiere una cuenta de escaneo.

Preparación y ejecución de los análisis

Con Node.js 24 instalado, se puede reproducir el proyecto:

git clone https://github.com/GabrielaCohailaAlvaradoE/notas-seguras-sast.git
cd notas-seguras-sast
npm ci
npm test
npm run scan:eslint

Para ejecutar Bearer, utilizar Linux x86_64 o Ubuntu en WSL. Desde la raíz del mismo repositorio:

bash scripts/install-bearer.sh
bash scripts/scan-bearer.sh
node scripts/summarize.mjs

El instalador descarga Bearer 2.1.1 de su publicación oficial y verifica el archivo con la suma SHA256 publicada para esa versión. El script analiza primero examples/vulnerable/ y después app/, genera informes JSON y produce también SARIF para el código corregido. reports/ contiene los resultados de cada ejecución; evidence/ conserva una instantánea verificable de la ejecución enlazada.

Para abrir la aplicación localmente, ejecutar npm start y visitar http://127.0.0.1:4173.

Hallazgo 1 y 2: inserción de texto como HTML

Las implementaciones vulnerables del título y la descripción usaban este patrón:

export function renderTitle(element, userInput) {
  element.innerHTML = userInput;
}

El navegador interpreta el contenido asignado a innerHTML como marcado. Si esa entrada está controlada por un atacante, puede introducir contenido activo y generar riesgo de XSS. En esta aplicación local, la exposición depende de cómo llegue la entrada al navegador; no afirmamos que exista un servidor multiusuario comprometido.

Bearer reportó dos hallazgos altos de la regla javascript_lang_dangerous_insert_html, asociados a CWE-79, en las líneas 4 y 7 de examples/vulnerable/rendering.js. ESLint señaló las mismas asignaciones con no-unsanitized/property.

Las tareas no necesitan contenido HTML enriquecido, por lo que corregimos ambas funciones con textContent:

export function renderTitle(element, userInput) {
  element.textContent = userInput;
}

Con este cambio, los datos se presentan como texto. Una entrada como <b>Prueba de texto</b> se muestra literalmente, sin convertirse en marcado. Esta comprobación visual relaciona la corrección con un comportamiento observable.

Hallazgo 3: evaluación dinámica de los minutos

El componente vulnerable para interpretar minutos utilizaba:

export function parseMinutes(userInput) {
  return eval(userInput);
}

eval puede interpretar la entrada como JavaScript, aunque el propósito del campo sea registrar una duración. La regla no-eval de ESLint detectó esta operación en la línea 4 de examples/vulnerable/core.js. Bearer no la reportó en este ejemplo; no le atribuimos ese hallazgo.

La corrección elimina la evaluación de expresiones y valida el dominio permitido:

export function parseMinutes(userInput) {
  const value = String(userInput).trim();
  if (!/^\d{1,4}$/.test(value)) {
    throw new Error('Usa minutos enteros entre 1 y 1440.');
  }
  const minutes = Number(value);
  if (minutes < 1 || minutes > 1440) {
    throw new Error('Usa minutos enteros entre 1 y 1440.');
  }
  return minutes;
}

Una entrada como 25 es válida; 20+5, valores fuera de rango o código JavaScript se rechazan. El producto necesita minutos enteros, no una calculadora de expresiones.

Resultados después de corregir

Punto del código vulnerable	Bearer CLI	ESLint	Corrección
Título, `rendering.js:4`	XSS alto, CWE-79	`no-unsanitized/property`	`textContent`
Descripción, `rendering.js:7`	XSS alto, CWE-79	`no-unsanitized/property`	`textContent`
Minutos, `core.js:4`	No reportado en este caso	`no-eval`	Validación y `Number`

Medición	Componentes vulnerables	Aplicación corregida
Hallazgos de Bearer	2 altos	0
Errores de reglas de ESLint	3	0
Pruebas de regresión aprobadas	No aplica	5

Son tres puntos inseguros, no cinco vulnerabilidades diferentes: los dos analizadores coinciden en las inserciones HTML. Tampoco se debe equiparar un error de regla de ESLint con la escala de severidad de Bearer.

Las pruebas comprueban límites válidos de minutos, rechazo de expresiones y código, uso de texto en ambos renderizadores, manejo de JSON local dañado y filtrado de registros inválidos con un límite de almacenamiento. La app incluye además una política CSP, pero la desaparición de las alertas se debe a corregir las funciones, no a ocultar los hallazgos.

Automatización de los controles y del despliegue

El archivo .github/workflows/security-and-deploy.yml se activa con pushes a main, solicitudes de cambio y ejecuciones manuales. Su trabajo security realiza los siguientes pasos:

Descarga el código e instala Node.js 24.
Reproduce las dependencias con npm ci y ejecuta las cinco pruebas.
Analiza la baseline y la aplicación con ESLint.
Instala Bearer, verifica SHA256 y analiza ambos alcances.
Genera el resumen y guarda el artefacto security-reports.
Construye la app y prepara los archivos para Pages.

El despliegue se ejecuta después y únicamente para main, fuera de las solicitudes de cambio. La dependencia fundamental es:

deploy:
  needs: security
  permissions:
    pages: write
    id-token: write

Si falla el trabajo de seguridad, no se publica esa nueva versión. El sitio previamente desplegado puede seguir disponible. El trabajo de análisis tiene permiso de lectura; los permisos de publicación se conceden en el trabajo de despliegue.

La baseline contiene problemas intencionales, así que el script de Bearer espera código de salida 1 en ese análisis. En cambio, el escaneo de app/ debe finalizar con éxito normal. No se fuerza --exit-code 0 ni se aplica continue-on-error al control de la aplicación publicable. El comparador de ESLint exige tres errores en los componentes educativos y cero en la app.

La construcción copia exclusivamente seis archivos de app/; no publica los ejemplos vulnerables, los scripts ni node_modules. Las acciones de GitHub están fijadas por SHA de commit y las dependencias de Node por versión y lockfile. Los informes de Actions se conservan siete días, y la copia versionada en evidence/ conserva la ejecución de referencia.

Publicación en un proveedor SaaS público

Configuramos GitHub Actions como origen de publicación en Settings → Pages. GitHub Pages aloja la aplicación estática mediante HTTPS. El proyecto utiliza un repositorio público y runners estándar ubuntu-latest, sin contratar servicios de pago ni configurar una clave personal de nube en el código.

La ejecución enlazada terminó con security y deploy en estado satisfactorio. El sitio respondió HTTP 200 y verificamos en el navegador la creación de tareas y la presentación literal de etiquetas. Así, la evidencia conecta el código, el análisis, la automatización y la aplicación disponible públicamente.

Conclusiones del equipo

La comparación mostró una diferencia útil de cobertura: Bearer detectó las dos inserciones HTML inseguras y ESLint añadió el uso de eval. Corregir las operaciones y comprobar el comportamiento permitió pasar de 2 a 0 hallazgos en Bearer, de 3 a 0 errores en ESLint y obtener cinco pruebas aprobadas.

Integrar estos controles antes del despliegue permite que sus resultados influyan en lo que se publica. Sin embargo, cero hallazgos describe las reglas, versiones y alcance utilizados; no demuestra seguridad absoluta. Quedan fuera una auditoría completa, pruebas dinámicas y una evaluación SCA como parte de esta comparación. La aplicación guarda notas locales sin cifrado propio y no debe utilizarse para información sensible.