Vulnerable Bank Application 🏦

A deliberately vulnerable web application for practicing application security testing of Web, APIs and LLMs, secure code review and implementing security in CI/CD pipelines.

⚠️ WARNING: This application is intentionally vulnerable and should only be used for educational purposes in isolated environments.

Overview

This project is a simple banking application with multiple security vulnerabilities built in. It's designed to help security engineers, developers, interns, QA analyst and DevSecOps practitioners learn about:

• Common web application and API vulnerabilities
• AI/LLM Vulnerabilities
• Secure coding practices
• Security testing automation
• DevSecOps implementation

Features & Vulnerabilities

Core Banking Features

• 🔐 User Authentication & Authorization
• 💰 Account Balance Management
• 💸 Money Transfers
• 📝 Loan Requests
• 👤 Profile Picture Upload
• 📊 Transaction History
• 📈 Transaction Analytics Dashboard (GraphQL-backed)
• 🔑 Password Reset System (3-digit PIN)
• 💳 Multi-Currency Virtual Cards Management
• 💱 Virtual Card Funding from Main USD Balance with built-in currency conversion (USD, GBP, NGN, JPY, EUR, QAR, BTC, ETH)
• 🛒 Public Merchant Payment API for intentionally vulnerable ecommerce/demo integrations
• 📱 Bill Payments System
• 🤖 AI Customer Support Agent (Real LLM with DeepSeek API / Mock Mode)

Implemented Vulnerabilities

1. Authentication & Authorization

   • SQL Injection in login
   • Weak JWT implementation
   • Broken object level authorization (BOLA)
   • Broken object property level authorization (BOPLA)
   • Mass Assignment & Excessive Data Exposure
   • Weak password reset mechanism (3-digit PIN)
   • Token stored in localStorage
   • No server-side token invalidation
   • No session expiration

2. Data Security

   • Information disclosure
   • Sensitive data exposure
   • Plaintext password storage
   • SQL injection points
   • Debug information exposure
   • Detailed error messages exposed

3. Transaction Vulnerabilities

   • No amount validation
   • Negative amount transfers possible
   • No transaction limits
   • Race conditions in transfers and balance updates
   • Transaction history information disclosure
   • No validation on recipient accounts

4. File Operations

   • Unrestricted file upload
   • Path traversal vulnerabilities
   • No file type validation
   • Directory traversal
   • No file size limits
   • Unsafe file naming
   • Server-Side Request Forgery (SSRF) via URL-based profile image import

5. Session Management

   • Token vulnerabilities
   • No session expiration
   • Weak secret keys
   • Token exposure in URLs

6. Client and Server-Side Flaws

   • Cross Site Scripting (XSS)
   • Cross Site Request Forgery (CSRF)
   • Insecure direct object references
   • No rate limiting

7. Virtual Card Vulnerabilities

   • Mass Assignment in card limit updates
   • Mass Assignment in card funding exchange-rate handling
   • Predictable card number generation
   • Plaintext storage of card details
   • No validation on card limits
   • BOLA in card operations
   • Race conditions in balance updates
   • Card detail information disclosure
   • No transaction verification
   • Lack of card activity monitoring
   • Client-controlled currency conversion during card funding

8. Bill Payment Vulnerabilities

   • No validation on payment amounts
   • SQL injection in biller queries
   • Information disclosure in payment history
   • Predictable reference numbers
   • Transaction history exposure
   • No validation on biller accounts
   • Race conditions in payment processing
   • BOLA in payment history access
   • Missing payment limits

9. Merchant Payment API Vulnerabilities

   • Plaintext merchant passwords and API keys
   • API keys returned in registration and login responses
   • Raw card number/CVV accepted by merchant payment APIs
   • SQL injection-prone merchant and card lookups
   • Missing idempotency, replay protection, payment limits, and rate limiting
   • Object-level authorization gaps in merchant payment lookup
   • Detailed payment decline reasons and debug data exposure
   • Predictable authorization code generation

10. AI Customer Support Vulnerabilities

• Prompt Injection (CWE-77)
• AI-based Information Disclosure (CWE-200)
• Broken Authorization in AI context (CWE-862)
• AI System Information Exposure (CWE-209)
• Insufficient Input Validation for AI prompts (CWE-20)
• Direct Database Access through AI manipulation
• AI Role Override attacks
• Context Injection vulnerabilities
• AI-assisted unauthorized data access
• Exposed AI system prompts and configurations

11. GraphQL Vulnerabilities

• Enabled schema introspection on the transaction analytics endpoint
• Weak JWT-based authentication inherited by /graphql
• SQL injection in GraphQL resolver query construction
• Missing GraphQL depth / complexity controls
• Raw GraphQL error disclosure
• Transaction analytics exposure through admin-scoped queries

Installation & Setup 🚀

Prerequisites

• Docker and Docker Compose (for containerized setup)
• PostgreSQL (if running locally)
• Python 3.9 or higher (for local setup)
• Git

Option 1: Using Docker (Recommended)

Using Docker Compose (Easiest)

1. Clone the repository:

git clone https://github.com/Commando-X/vuln-bank.git
cd vuln-bank

2. Start the application:

docker-compose up -d --build

The application will be available at http://localhost:5000

Container recovery behavior

The Docker setup includes a few operational safeguards so the app can recover without manual SSH intervention:

• web and db use restart: unless-stopped, so Docker restarts them automatically if the process exits.
• db exposes a health check, and web waits for Postgres readiness before starting.
• web runs the Flask development server with debug=True (intentional — preserves the training scenarios that target the Werkzeug debugger).
• web exposes GET /healthz so the container can report whether the app and database are actually usable.

This keeps the intentionally vulnerable application behavior intact while making the container lifecycle more resilient.

Local smoke test

You can validate the local runtime wiring without starting real containers:

python3 -m unittest discover -s tests -v

This checks the /healthz endpoint behavior and verifies that start.sh waits for the database and then launches the Flask app. If the Flask app dependencies are not installed in your current Python environment, the /healthz route test is skipped and the startup-script smoke test still runs.

Using Docker Only

1. Clone the repository:

git clone https://github.com/Commando-X/vuln-bank.git
cd vuln-bank

2. Build the Docker image:

docker build -t vuln-bank .

3. Run the container:

docker run -p 5000:5000 vuln-bank

Option 2: Local Installation

Prerequisites

• Python 3.9 or higher
• PostgreSQL installed and running
• pip (Python package manager)
• Git

Steps

1. Clone the repository:

git clone https://github.com/Commando-X/vuln-bank.git
cd vuln-bank

2. Create and activate a virtual environment (recommended):

# On Windows
python -m venv venv
venv\Scripts\activate

# On Linux/Mac
python3 -m venv venv
source venv/bin/activate