A Next.js Honey Pot application designed to lure attackers, simulate vulnerabilities (like shell access), and log their activities for security analysis.
An interactive full-stack Honeypot application designed for enterprise security research and attacker behavior monitoring. Developed as part of an advanced enterprise security architecture course (5A Architecture Sécurisée Entreprise), the application simulates a realistic administration panel containing highly confidential business documents and deliberate, strategically placed security vulnerabilities. Attackers are lured into standard entry vectors, such as brute-forcing administrative logins or exploring administrative interfaces, where they discover an exposed, unauthenticated database access point (/api/admin/data) and an un-sanitized interactive shell command execution endpoint (/api/shell). In the background, the honeypot silently and comprehensively logs all interactions—including brute-force attempts with credentials tried, client IP addresses, user agents, API statuses, and commands executed in the shell—providing deep insights into attacker methodology. The application is completely containerized via Docker and orchestrated with Docker Compose, ensuring a secure, sandboxed execution environment that isolates the host system from malicious commands run by attackers.
Command execution response under 50ms (local/containerized exec overhead), with simulated UX delays of 500ms to 2000ms for admin pages to mimic network latency and maintain the illusion of a complex remote server.
Lighthouse Performance score of 98/100, featuring instant initial loads, highly responsive custom CSS animations, and a React 19 concurrent-safe client state flow.
$0/month. The entire sandbox runs locally via lightweight Docker containers, isolating the application from the host and consuming minimal resources (under 250MB RAM for the full stack).
Intentionally Engineered Security Defects: Designed and deployed deliberate, realistic vulnerabilities, including an unauthenticated data leakage API (/api/admin/data) and an un-sanitized shell execution parameter (/api/shell), mimicking common misconfigurations.
Comprehensive Forensic Logging Layer: Implemented a custom server-side logging mechanism that captures attacker telemetry, recording precise timestamps, client IP addresses (x-forwarded-for), browser user-agents, failed login credentials (brute-force monitoring), and executed shell commands directly to a centralized log file (honeypot.log).
Sandboxed Containerization & DevSecOps Isolation: Containerized the application stack using Node.js and PostgreSQL services, mapping container ports securely and implementing isolation boundaries to prevent commands executed via the exposed shell from compromising the host infrastructure.
Relational Database Seeding for Realism: Programmed a seed script using Prisma and Faker to populate the PostgreSQL database with 147 mock confidential documents and 312 historical fake login attempts, establishing a highly authentic 'honeypot lure' that keeps attackers engaged.
Exhaustive situation-action-result breakdowns showcasing problem-solving and architectural execution.
A honeypot is useless if attackers quickly realize it is a fake environment. It needs to look authentic, contain believable data, and feature subtle but discoverable vulnerabilities rather than obvious traps.
I used Prisma and Faker to seed the database with 147 unique, professional-looking confidential documents with varying levels of classification (RESTRICTED, CONFIDENTIAL, TOP SECRET). I also populated 312 fake login attempts with random IPs and user agents to simulate a live, highly-active target. Furthermore, the frontend implements custom artificial delays (500ms to 2000ms) when querying the backend to emulate realistic server-side processing times for sensitive databases.
Low-level component relationships, system boundaries, and runtime flows.
The system's architecture is a multi-tier sandbox environment orchestrated entirely via Docker and Docker Compose.
Modern Next.js 16 App Router Core: Crafted the application with Next.js 16 (App Router), React 19, and Tailwind CSS v4, styling a dark-themed glassmorphism interface ('liquid-glass') that displays fake administrative data once authenticated.
Robust Input Validation Core: Integrated React Hook Form with Zod schemas to enforce client-side constraints, demonstrating that while the backend has intentional holes, standard front-end input rules remain intact to keep up the appearance of a standard app.
The simulated environment perfectly mimics an active, high-value enterprise administration server, enticing attackers to spend more time performing reconnaissance and executing payloads, which maximizes logging efficiency.
The honeypot must record every single step of the attacker—including failed login payloads (brute-force credentials), system commands, and headers—without crashing, raising security warnings, or showing errors that would tip off the hacker.
I developed custom logging functions in the Next.js API routes (/api/auth/login and /api/shell). In the authentication route, I intercepted the exact login/password inputs and logged them directly to a server-side honeypot.log file alongside their IP address (x-forwarded-for) and User Agent. In the shell execution route, all incoming shell commands are recorded before execution.
Administrators can monitor attacker behavior in real time by executing 'make logs' (mapping to 'tail -f /app/logs/honeypot.log'). The logging mechanism is silent, fast, and does not leak any operational indicators to the attacker's client.
Exposing an endpoint like /api/shell that executes raw commands on the host is highly dangerous. If an attacker gains access to the shell, they could potentially compromise the host system, infect the local network, or access private files.
I packaged the entire architecture into a multi-container Docker Compose setup. The Next.js application runs inside a distinct 'web' container using Node 22, while the Postgres database runs in an isolated 'db' container. Crucially, the web container is restricted to its virtualized workspace, limiting any shell commands executed via /api/shell to the containerized environment.
The host system is completely safe and isolated. Even if an attacker executes destructive commands (e.g., 'rm -rf /' or background cryptominers), they only damage the volatile container environment, which can be immediately restored to a clean state by running 'make clean && make start'.
