Security research lab demonstrating how API gateway misconfiguration creates exploitable attack chains. Uses Kong as a real-world example, but lessons apply to all API gateways.
This is a standalone educational security lab about Kong API Gateway.
- Kong-focused — Demonstrates misconfiguration risks in Kong API Gateway (v1.x through 3.x)
- Universally applicable — Principles and defense strategies apply to all API gateways (NGINX, AWS API Gateway, etc.)
- For learning & authorized testing only — Educational content, threat modeling, and secure deployment patterns
- Independent research — Standalone security education resource
- Scope
- ⚡ Complete Step-By-Step Lab — Start here
- Quick Links
- Why This Matters
- The Three-Control Problem
- Quick Start
- Defense Strategy
- FAQ
- What's Included
- Kong Technology Stack
- License
Start here: RUN_THE_LAB.md
Complete walkthrough (120 minutes total):
- Part 1 - Start Kong (10 min) - Use docker-compose.yml
- Part 2 - Understand the vulnerability (20 min) - Read technical docs
- Part 3 - Run automated tests (15 min) - Execute poc/vulnerability-chain-test.sh
- Part 4 - Try the browser-based attack (30 min) - Use poc/attack.html or create backdoor manually
- Part 5 - Deploy securely (30 min) - Fix all three misconfigurations
- Part 6 - Validate security (15 min) - Re-run tests, verify safe state
- Part 7 - Clean up (5 min) - Remove containers
Each part is numbered steps you can follow along with.
| Resource | Purpose |
|---|---|
| RUN_THE_LAB.md | Complete 120-min step-by-step walkthrough (7 parts) |
| docker-compose.yml | Vulnerable Kong setup - fastest start (2 commands) |
| docs/MEDIUM.md | Technical deep-dive with attack flow diagrams |
| poc/attack.html | Interactive browser-based attack demo |
| poc/vulnerability-chain-test.sh | Automated vulnerability test suite |
| docs/QUICK_REFERENCE.md | Defense checklist & secure config examples |
| docs/THREAT_MODEL.md | STRIDE/DREAD analysis & incident response |
Misconfigured API gateways are a critical attack surface. Three individually documented features—CORS, admin API access, and code execution—when misconfigured together, create a complete remote code execution chain exploitable through social engineering alone. This lab teaches why defense-in-depth matters: no single control is sufficient.
Get Kong running in 2 commands:
docker-compose up -d # Starts vulnerable Kong (postgres + Kong)
bash poc/vulnerability-chain-test.sh # Run automated testsTest the attack in your browser:
# Open in browser:
file://$(pwd)/poc/attack.html
# Or serve it: python3 -m http.server 8080, then visit http://localhost:8080/poc/attack.htmlExpected output: All tests show ✓ VULNERABLE (as configured deliberately for learning).
This attack requires ALL THREE of these misconfigurations:
┌─────────────────────────────────────┐
│ Port 8001 Accessible? │
│ CORS Origin Reflected? │ ─→ Missing ANY ONE?
│ Lua FFI Enabled? │ Attack FAILS
└─────────────────────────────────────┘
▼
ALL THREE
▼
RCE as Kong Process
| Control | Safe | Vulnerable |
|---|---|---|
| Network | Port 8001 blocked (localhost only) | Port 8001 open to network |
| CORS | Specific origin whitelist | Reflects * or arbitrary origins |
| Config | untrusted_lua = off |
untrusted_lua = on |
If ANY control is properly implemented, the attack chain breaks.
All three must be true simultaneously:
- Port 8001 Accessible - Admin's browser can reach Kong admin API
- CORS Origin Reflection Enabled - Kong reflects arbitrary origins in responses
- Lua FFI Enabled -
untrusted_lua = onallows plugin code execution
# Firewall: Block external access to port 8001
iptables -A INPUT -p tcp --dport 8001 -s 127.0.0.1 -j ACCEPT
iptables -A INPUT -p tcp --dport 8001 -j DROPPrevents 99% of attacks. This single control often sufficient.
# Kong config
admin_gui_auth: basic_auth
admin_gui_session_secret: <random-64-chars>Requires credentials for admin API access.
# Kong config
untrusted_lua: off # Disable Lua FFI
cors:
origins:
- "https://legitimate-domain.com" # Specific whitelist, no wildcard| Environment | Risk | Why |
|---|---|---|
| Production | LOW | Firewalls, authentication, locked-down config |
| Staging | HIGH | Often mimics prod but less strictly managed |
| Development | CRITICAL | Port-forwards open, CORS wildcard, custom plugins |
| Kubernetes (port-forward) | CRITICAL | kubectl port-forward to port 8001 |
Q: Is Kong vulnerable by default?
A: No. Kong 2.0+ defaults to admin_listen = 127.0.0.1:8001 (safe). Kong 1.x defaulted to 0.0.0.0:8001. Proper configuration is essential.
Q: Can a single control prevent this attack?
A: Yes. Network isolation alone (blocking port 8001) prevents 99% of cases. Defense-in-depth is best practice.
Q: Should we stop using Kong?
A: No. Kong is secure when properly configured. This research demonstrates misconfiguration risk—applicable to all API gateways.
Q: Which Kong versions are affected?
A: All versions can be misconfigured this way. Defaults improved in Kong 2.0+. Test your version at curl localhost:8001/status.
Q: What should I do if I detect signs of attack?
A: 1) Check Kong logs for POST /admin/plugins from unexpected sources
2) Verify CORS is properly restricted
3) Confirm untrusted_lua = off
4) Isolate port 8001 immediately
5) Review incident response playbook in docs/THREAT_MODEL.md
Q: Can I test this on my own Kong instance?
A: Yes! Use poc/attack.html to test your Kong endpoint. Or run poc/vulnerability-chain-test.sh from command line.
Q: Does this apply to other API gateways?
A: Yes. CORS reflection, unauthenticated admin APIs, and code execution are risks across NGINX, AWS API Gateway, Traefik, etc. Principles are universal.
Q: How do I secure Kong on Kubernetes?
A: Use helm-configs/kong-secure-deployment.yaml. Key settings:
admin_listen = 127.0.0.1:8001(no network access)admin_gui_auth = basic_auth(require credentials)untrusted_lua = off(disable FFI)
Understanding Kong's architecture is essential for securing it.
| Component | Technology | Security Relevance |
|---|---|---|
| Runtime | Lua (OpenResty/LuaJIT) | FFI enables direct system calls |
| Core | C + Lua | High-performance, but FFI allows code execution |
| Database | PostgreSQL | Stores Kong configuration, plugin metadata |
| Admin API | HTTP/REST (port 8001) | Unauthenticated by design, assumes network isolation |
| Proxy | HTTP/HTTPS (ports 8000/8443) | Handles all upstream traffic |
| OS | Linux (primary), macOS, Windows | Process runs as configured user (often root) |
| Plugins | Lua modules | Custom code execution via plugin framework |
| Process User | root (common default) | Privilege level determines attack impact |
Getting Started:
- Complete Lab Guide (
RUN_THE_LAB.md) - Step-by-step walkthrough (120 minutes, 7 parts) - Docker Setup (
docker-compose.yml) - Spin up Kong in 2 commands
Documentation:
- Article (
docs/MEDIUM.md) - Complete 14-section technical article with mermaid diagrams - Threat Model (
docs/THREAT_MODEL.md) - STRIDE analysis with DREAD scoring, incident response - Education Guide (
docs/EDUCATION_GUIDE.md) - 5-level structured learning path with labs - Quick Reference (
QUICK_REFERENCE.md) - Defense checklist and testing commands - Learning Resources (
RESOURCES.md) - 80+ curated links (Kong docs, OWASP, PortSwigger, academic research)
Lab Components:
- Attack Demo (
poc/attack.html) - Interactive browser-based attack demonstration (styled UI, real-time logging) - Automated Tests (
poc/vulnerability-chain-test.sh) - 6-part vulnerability test suite - Kubernetes (
helm-configs/kong-secure-deployment.yaml) - Secure Kong Helm deployment - AWS/Terraform (
terraform-configs/) - Production-grade infrastructure-as-code with initialization script - Repository Summary (
docs/REPO_SUMMARY.py) - Project metadata and structure
All testing conducted on isolated mock servers only. No production Kong instances tested.
- CORS header reflection
- Admin API unauthenticated access
- Lua FFI payload execution
- Complete browser-based attack chain
- CORS reflection: Confirmed vulnerable
- Admin API: Confirmed unauthenticated
- Plugin creation: Confirmed accessible
- FFI code execution: Confirmed functional
- End-to-end chain: Successful RCE
This is educational research on API gateway configuration risks.
- Only test on systems you own or have explicit written authorization to test
- Never test against production systems
- Kong's default configuration prevents this attack entirely
- Attack requires deliberate misconfiguration of all three security boundaries
- Defense-in-depth principle applies—layered controls prevent exploitation
This repository is for educational and authorized security testing purposes. Contributions welcome for:
- Additional detection methods
- Enhanced mitigation strategies
- Secure deployment patterns for other platforms
- Documentation improvements
This research is provided for educational purposes under the MIT License.
See LICENSE file for complete terms, including educational disclaimer and responsible use guidelines.
- Kong team for transparent security practices and documentation
- PortSwigger Web Security Academy for CORS vulnerability research
- Sonar Security for origin reflection vulnerability analysis
- OWASP for security testing methodology and standards
Last Updated: April 2026
Status: Production Ready
Framework: STRIDE + DREAD + OWASP API Security Top 10
For comprehensive learning resources, see RESOURCES.md
For threat modeling details, see docs/THREAT_MODEL.md
For deployment examples, see helm-configs/ and terraform-configs/