DEV Community: Andrés Caso Iglesias

Scanner de Seguridad Web Full-Stack con NestJS y React — construido para el Evolve Talent Day

Andrés Caso Iglesias — Mon, 01 Jun 2026 21:12:31 +0000

He creado una herramienta de auditoría de headers de seguridad que analiza 15 parámetros OWASP, TLS, DNS, fingerprinting tecnológico, CVEs, y mapea contra 4 marcos de cumplimiento. Todo con SSRF protection, SSE en tiempo real, y Docker multi-stage. La estoy presentando en el Evolve Talent Day para darme a conocer como nuevo talento en el ecosistema.

¿Por qué este proyecto?

Cuando empiezas en ciberseguridad, uno de los primeros consejos que te dan es: "analiza los headers de seguridad de una web". Hazlo una vez. Dos. Diez. Después te aburres.

Lo que no te dicen es que entender por qué un header está mal configurado, qué frameworks de cumplimiento afecta, y cómo priorizar las recomendaciones es un ejercicio completamente diferente a simplemente ejecutar un curl -I.

Quise construir eso: una herramienta que no solo diga "te falta CSP", sino que te explique el impacto, te mapee contra OWASP Top 10, NIS2, ENS e ISO 27001, y te genere un reporte exportable. Un proyecto de fin de máster que sea realmente útil y que me permita demostrar lo que sé.

Y como estoy participando en el Evolve Talent Day — un evento de Evolve para dar a conocer nuevo talento en el ecosistema tech — quise que este proyecto tuviera la calidad suficiente para presentarlo con orgullo.

¿Qué hace exactamente?

Dale una URL pública y la herramienta:

Hace un request HTTP a esa URL (con protección SSRF, que después explico)
Analiza 15 headers de seguridad contra el OWASP Secure Headers Project
Verifica TLS/SSL — protocolo, certificado, cadena de confianza
Revisa registros DNS — SPF, DKIM, DMARC
Detecta archivos sensibles expuestos — .env, .git/config, wp-config.php, 40 rutas en total
Analiza SRI (Subresource Integrity) en scripts y estilos externos
Hace fingerprinting tecnológico — detecta 23 tecnologías y busca CVEs asociadas
Mapea contra 4 marcos de cumplimiento: OWASP Top 10, NIS2, ENS, ISO 27001
Calcula un score de seguridad (0-100) con calificación A-F
Genera reportes exportables en PDF y JSON

Todo esto con progreso en tiempo real vía Server-Sent Events. No es un spinner que dice "escaneando...". Son 9 etapas con feedback granular.

El Stack (sí, usé todo lo último)

Backend — NestJS 11

Componente	Tecnología
Runtime	Node.js 22
Framework	NestJS 11
HTTP Client	Axios
Validación	class-validator + Zod (env)
Rate Limiting	@nestjs/throttler
Auth	API Key (custom guard)
DB	SQLite via better-sqlite3 (WAL mode)
PDF	PDFKit
TLS	Módulo nativo `tls`
DNS	Módulo nativo `dns/promises`
API Docs	Swagger/OpenAPI

Frontend — React 19

Componente	Tecnología
Framework	React 19.2
Bundler	Vite 8
Styling	Tailwind CSS 4
Charts	Chart.js
State	Custom hooks
Real-time	SSE via EventSource
Testing	Vitest + React Testing Library

DevOps

Componente	Detalle
Containers	Docker multi-stage builds
Compose	2 servicios: backend + frontend
CI/CD	GitHub Actions: jobs paralelos
Proxy	Nginx con SSE buffering deshabilitado

Decisiones Arquitectónicas que me Enorgullecen

1. SSRF Protection en Cada Request Saliente

Esta es la decisión de la que más orgulloso estoy. Un scanner de seguridad no puede ser vulnerable a SSRF. Sería un chiste.

La función resolveAndCheckHostname() se ejecuta antes de cada request HTTP que hace el scanner — ya sea al target, a OSV.dev para CVEs, o a cualquier otro lado:

// Bloquea rangos IPv4 privados
if (isPrivateIPv4(ip)) {
  throw new ForbiddenException(`SSRF blocked: ${hostname} resolves to private IP ${ip}`);
}

// Bloquea loopback IPv6 y link-local
if (ip === '::1' || ip.startsWith('fe80:')) {
  throw new ForbiddenException(`SSRF blocked: ${hostname} resolves to ${ip}`);
}

Resuelve el DNS, verifica todas las IPs retornadas, y solo procede si ninguna es privada. Esto previene que la herramienta sea usada como vector de ataque.

2. Strategy Pattern para Header Checkers

Cada uno de los 15 headers tiene su propio checker class que implementa una interfaz común:

interface HeaderChecker {
  name: string;
  severity: 'critical' | 'high' | 'medium' | 'low';
  weight: number;
  analyze(headers: Record<string, string>): HeaderResult;
}

El AnalyzerService inyecta los 15 checkers vía DI y los itera automáticamente. ¿Quieres agregar un header nuevo? Creas la clase, la agregas al contenedor DI, y listo. Sin tocar el servicio de análisis.

3. Paralelismo con SSE

El scanCore() ejecuta 7 subsistemas en paralelo con Promise.all:

HTTP Client ─────┐
TLS Checker ─────┤
DNS Checker ─────┤
Security Files ──┼──▶ Promise.all ──▶ Analyze ──▶ Comply ──▶ Report
Sensitive Files ─┤
SRI Checker ─────┤
Fingerprinting ──┘

Cada subsistema emite eventos SSE (scanning → complete), y el frontend los consume en tiempo real con EventSource. El usuario ve exactamente en qué etapa está el scan.

4. Detección de Soft 404

Al probar las 40 rutas sensibles, un sitio podría devolver HTTP 200 con una página de error custom. El SensitiveFileCheckerService detecta esto:

Si el status es 200 pero Content-Type es text/html y Content-Length > 500 → suspected soft 404 con confianza baja
Si el status es 200 con Content-Type tipo JSON o texto plano → probablemente real

Esto reduce falsos positivos, que en una herramienta de seguridad son el enemigo.

5. CVE Dual: Local + OSV.dev

Mantengo una base de datos local de 20 CVEs (WordPress, Joomla, Drupal, PHP, Apache, Nginx) con matchers de rango de versiones. En paralelo, consulto la API de OSV.dev (la base de datos de vulnerabilidades de Google) con caché in-memory de 30 minutos.

Si OSV.dev está caído, la herramienta sigue funcionando con la base local. Si está disponible, fusiona los resultados. Resiliencia y profundidad.

6. Zod-First Environment Validation

Las 16 variables de entorno se validan al startup con un schema Zod. Si alguna es inválida, la aplicación se niega a arrancar:

const envSchema = z.object({
  PORT: z.coerce.number().default(3000),
  API_KEY: z.string().optional(),
  CORS_ORIGINS: z.string().default('http://localhost:5173'),
  // ... 13 variables más
});

Fail-fast. No surprises en producción.

El Frontend: No es Solo un CRUD Bonito

El frontend tiene 8 secciones tabulares:

Headers — Grid filtrable de 15 tarjetas con badges de severidad, barras de grade, findings y recomendaciones
Compliance — Grid de 4 columnas (OWASP/NIS2/ENS/ISO27001) con scores porcentuales y dots de estado por control
TLS/SSL — Versión del protocolo, detalles del certificado, grade
DNS — Records SPF/DKIM/DMARC con grades
SRI — Análisis de integridad de recursos externos
Fingerprinting — Tecnologías detectadas con niveles de confianza, lista de CVEs
Sensitive Files — Archivos expuestos con ratings de confianza
Recommendations — Lista priorizada de todos los subsistemas

Detalles que Importan

Error boundaries granulares: Cada sección tiene su propio <ErrorBoundary>. Si ComplianceGrid crashea, el resto sigue funcionando.
Clasificación de errores: El hook useScan clasifica errores en 5 tipos (network, timeout, server, validation, unknown) y muestra diferentes tratamientos UI con mensajes en español.
Score Circle animado: SVG animado con tooltip que explica la metodología: Score = sum(weight × grade) / 165 × 100.
Transparencia sobre limitaciones: El scoring es un heurístico autor-definido, no un estándar. El frontend lo documenta explícitamente.

DevOps: Docker y CI/CD

Docker Multi-Stage

# Builder stage
FROM node:22-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

# Runner stage
FROM node:22-alpine AS runner
RUN addgroup -g 1001 -S appgroup && adduser -S appuser -u 1001 -G appgroup
WORKDIR /app
COPY --from=builder --chown=appuser:appgroup /app/dist ./dist
COPY --from=builder --chown=appuser:appgroup /app/node_modules ./node_modules
USER appuser

Non-root user en ambos contenedores. Multi-stage para minimizar el tamaño de imagen.

CI/CD con GitHub Actions

Dos jobs paralelos:

Backend: npm ci → lint → test → build
Frontend: npm ci → lint → test → build

Cada uno corre en Ubuntu con Node 22. Independientes pero simultáneos.

Nginx para el Frontend

location /api/ {
    proxy_pass http://backend:3000;
    proxy_buffering off;  # Soporte SSE
    proxy_http_version 1.1;
    proxy_set_header Connection '';
    chunked_transfer_encoding off;
}

El proxy_buffering off es crítico para que los eventos SSE lleguen al frontend sin buffering intermedio.

Test Coverage

Backend: 33 suites de test (unitarios + e2e)
Frontend: 8 archivos de test con Vitest + React Testing Library
E2E: Un test completo de la API de scan con supertest

No es 100% coverage, pero es testing real — no assertions vacías.

Lo que Aprendí Construyendo Esto

Seguridad no es un feature, es una mentalidad. La protección SSRF tiene que estar en cada capa, no solo en el endpoint principal.
SSE es superior a WebSocket para este caso. No necesitas bidireccionalidad. El servidor emite, el cliente consume. SSE es más simple, más ligero, y funciona con HTTP/1.1.
El Strategy Pattern no es académico, es útil. Los 15 header checkers son intercambiables, testeables, y extensibles. Si mañana necesito agregar un header, no toco código existente.
Docker multi-stage no es opcional, es hygiene. Un builder stage de 900MB y un runner de 150MB. La diferencia es inaceptable si no lo haces.
Zod al startup te salva de problemas en runtime. Fail-fast > fail-later. Siempre.

Evolve Talent Day

Estoy presentando este proyecto en el Evolve Talent Day, un evento organizado por Evolve para dar a conocer a nuevo talento en el ecosistema tech.

La idea es simple: mostrar lo que sé, cómo lo sé, y cómo lo aplico. No es un proyecto perfecto — es un proyecto real con decisiones arquitectónicas documentadas, trade-offs explícitos, y código que funciona.

Si estás en el evento o te interesa el proyecto, puedes:

Probarlo: Repositorio en GitHub
Leer la documentación: docs/ tiene versiones en inglés y español
Docker Compose: docker compose up levanta los dos servicios
API Docs: Swagger en /api/docs

¿Qué Sigue?

Autenticación JWT para escaneos privados
Dashboard multi-usuario con historial compartido
Comparación entre scans (delta analysis)
Integración con pipelines CI/CD (GitHub Action custom)
Más tecnologías en el fingerprinting (actualmente 23)
Base de CVEs expandida

Gracias por leer. Si tienes preguntas sobre la arquitectura, las decisiones técnicas, o quieres discutir sobre ciberseguridad, deja un comentario.

Y si estás en el Evolve Talent Day, acércate a charlar. Siempre hay algo nuevo que aprender.

Built with NestJS 11, React 19, Vite 8, Tailwind CSS 4, TypeScript, Docker, and too much café con leche.

Building a Portfolio That Actually Demonstrates Software Engineering

Andrés Caso Iglesias — Mon, 25 May 2026 18:37:08 +0000

After nearly 20 years leading teams in hospitality and logistics, I made a career change into software development. When it came time to build my portfolio, I made a deliberate choice: it would not be just a collection of screenshots and technology lists. It would be a working demonstration of how I think about software architecture.

This is the story of how I built it, the architectural decisions I made, and why I believe a portfolio should show process, not just results.

The Core Architecture: Separation of Concerns Done Right

The project follows a strict three-layer architecture with unidirectional dependencies:

Presentation (React components) -> Logic (pure functions) -> Data (typed static arrays)

No layer knows about the layers above it. Data is data. Logic is logic. Presentation is presentation.

The Data Layer: Typed and Explicit

Every piece of data in the portfolio has an explicit TypeScript interface. Here is the Project interface:

export interface Project {
  name: string;
  description: "string;"
  tech: string[];
  github: string;
  live: string | null;
  impact?: string;
  role?: string;
  enName?: string;
  enDescription?: string;
  challenge?: string;
  enChallenge?: string;
  solution?: string;
  enSolution?: string;
  architecture?: string;
  enArchitecture?: string;
  slug: string;
  erdPath?: string;
  snippetPaths?: string[];
}

Every field is typed. Every optional field is marked with ?. No any anywhere. The data files in src/data/ contain nothing but arrays and interfaces. No logic, no side effects, no React imports.

The Logic Layer: Pure Functions

All business logic lives in src/lib/ as pure functions. Here is an example: a function that takes raw TimelineItem data and calculates normalized percentage positions (0-100%) for the visual timeline layout:

export function calculateTimelinePositions(items: TimelineItem[]): TimelineItem[] {
  // Parse dates from Spanish month names
  const sortedTimelineData = items
    .map(item => ({
      ...item,
      sortDate: parseSpanishDate(item.startDateStr)
    }))
    .sort((a, b) => {
      if (!a.sortDate || !b.sortDate) return 0;
      if (a.sortDate.year !== b.sortDate.year) {
        return a.sortDate.year - b.sortDate.year;
      }
      return a.sortDate.month - b.sortDate.month;
    })
    .map(item => {
      const { sortDate, ...rest } = item;
      return rest;
    });

  // Find the global min/max dates to normalize
  const allDatesRaw = timelineData.flatMap(item => [
    parseSpanishDate(item.startDateStr),
    parseSpanishDate(item.endDateStr)
  ]);
  const allDates = allDatesRaw.filter(
    (d): d is { year: number; month: number } => d != null
  );

  // ... calculates percentage positions
  // startPos = (startMonthsFromMin / totalMonths) * 100
}

Key details:

The function takes data in, returns data out. No side effects.
It uses a TypeScript type guard (d): d is { year: number; month: number } instead of type assertions.
The percentage calculation is pure math: position = (time since min date) / (total timespan) * 100.
This is trivially testable without mocks.

The Presentation Layer: Smart Containers, Dumb Components

Components follow the container-presentational pattern. Containers manage state and pass props down. Presentational components just render.

// Timeline.tsx (container)
"use client";

import { rawTimelineData } from "@/data/timelineData";
import TimelineDesktop from "@/components/timeline/TimelineDesktop";
import TimelineMobile from "@/components/timeline/TimelineMobile";
import { useGlobalLang } from '@/hooks/useGlobalLang'

export default function Timeline() {
  const { lang } = useGlobalLang()
  return (
    <section className="py-20 bg-slate-900 overflow-hidden">
      <div className="w-full">
        <h2 className="text-3xl font-bold mb-16 text-white text-center">
          {t(lang, 'home.timelineTitle')}
        </h2>
        <TimelineDesktop items={rawTimelineData} />
        <TimelineMobile items={rawTimelineData} />
      </div>
    </section>
  );
}

The container decides which sub-component to render based on screen size. The sub-components (TimelineDesktop, TimelineMobile) receive data via props and just render it. No logic, no data fetching, no side effects.

The Bilingual System: CustomEvent Instead of Context

Instead of using React Context for language state (which causes unnecessary re-renders across the entire tree), I used a lightweight approach with localStorage and a global CustomEvent:

"use client";

export function useGlobalLang(): { lang: Lang; setLang: (l: Lang) => void } {
  const [lang, setLangState] = useState<Lang>('es')

  const setLang = (l: Lang) => {
    if (l !== 'es' && l !== 'en') return  // runtime type guard
    setLangState(l)
    localStorage.setItem('lang', l)
  }

  useEffect(() => {
    const onLangChanged = () => {
      const v = localStorage.getItem('lang') as Lang | null
      if (v === 'es' || v === 'en') setLangState(v)
    }
    window.addEventListener('langChanged', onLangChanged)
    return () => window.removeEventListener('langChanged', onLangChanged)
  }, [])

  return { lang, setLang }
}

Why this approach?

No Context means no tree re-renders when language changes.
The CustomEvent allows any component to trigger a language sync from anywhere.
The inline if (l !== 'es' && l !== 'en') guard catches invalid values at runtime, not just compile time.
Components opt into language reactivity only when they use the hook.

The Modal: Loading Code Snippets Asynchronously

Each project has associated code snippets stored in public/snippets/. The modal fetches them using Promise.all on mount:

"use client";

export default function Modal({ project, onClose }: ModalProps) {
  const { lang } = useGlobalLang();
  const [activeTab, setActiveTab] = useState<
    'challenge' | 'solution' | 'architecture' | 'snippets'
  >('challenge');
  const [snippetsContent, setSnippetsContent] = useState<
    {path: string, content: string}[]
  >([]);

  // Escape key handling and async snippet loading
  useEffect(() => {
    const handleEscape = (e: KeyboardEvent) => {
      if (e.key === 'Escape') onClose();
    };
    window.addEventListener('keydown', handleEscape);
    return () => window.removeEventListener('keydown', handleEscape);
  }, [onClose]);

  // Snippets are fetched asynchronously when tab switches
  // using Promise.all for parallel loading
}

The modal uses createPortal from React DOM to render outside the component tree, and Framer Motion for enter/exit animations. Focus management and keyboard navigation are handled with useEffect.

Visual Documentation: ERD Diagrams in SVG

Every project includes an Entity-Relationship Diagram as an SVG file. These are not third-party screenshots. They are hand-drawn SVGs designed to match the portfolio's dark theme (#0f172a background).

The SVG files live in public/erd/ and are referenced by each project's erdPath field. The modal renders them inline, allowing zoom and pan without external dependencies.

Currently, five ERDs are available:

Security Header Scanner (7 parallel checkers architecture)
Bolsa de Empleo (NestJS + PostgreSQL job platform)
FoodBites (Spring Boot food truck management)
Gestor de Huertos (urban garden management)
Portfolio itself (showing how all data layers connect)

The Technology Stack

Layer	Choice	Why
Framework	Next.js 16 (App Router)	Hybrid static/server rendering, auto code splitting
UI	React 19 with React Compiler	Automatic optimization, no manual useMemo
Language	TypeScript (strict: true)	Full type safety, no escape hatches
Styling	Tailwind CSS v4	Utility-first, zero unused CSS in production
Animations	Framer Motion	Accessible, performant animation primitives
Deployment	Vercel	Optimized for Next.js, global CDN

The tsconfig.json is configured with strict: true, moduleResolution: "bundler", and path aliases (@/* to ./src/*).

Lessons Learned

Start with architecture, not code. Before writing a single component, I planned the three-layer structure. This saved me from the "spaghetti refactor" that hits most side projects around month two.
Pure functions are a superpower. Every function in src/lib/ is testable without mocks. When I add features, I don't break existing logic. When I refactor components, the logic stays intact.
TypeScript strict mode is not optional. The type guard pattern ((d): d is T) is far safer than type assertions (as T). The compiler becomes your best code reviewer.
Documentation belongs alongside code. The ERD diagrams are not in a separate wiki. They are in public/erd/, referenced from the project data, and rendered in the same UI as the code. If the data model changes, the diagram is right there to update.
Bilingual content adds complexity, but not with the right abstraction. The useGlobalLang hook is 37 lines. The data layer uses optional en* fields. The t() function is a lookup. The whole i18n system is under 100 lines total.

What About the Career Change?

I spent 20 years managing teams in hospitality and logistics before moving into tech. That experience taught me things no bootcamp can teach: leading under pressure, communicating across roles, and understanding that code serves a business objective, not the other way around.

My portfolio is a reflection of that approach. It is not just a collection of projects. It is an argument for a certain way of thinking about software: layered, typed, documented, and built to last.