[opensourcedex]

vuln-bank is a free, open source ai security & privacy project written in HTML and released under MIT. It has 933 GitHub stars, 341 forks and 10 open issues, and was last pushed 7 days ago. On this registry it ranks #26 of 34 tracked projects in AI Security & Privacy, with 5 head-to-head comparisons available.

What is vuln-bank?

vuln-bank is a deliberately vulnerable banking application — MIT licensed, primarily written in HTML, with 933 stars and 341 forks — built so security engineers, developers, interns, QA analysts and DevSecOps practitioners can practise web, API and LLM application security testing, secure code review and CI/CD security automation in an isolated environment.

What it is

vuln-bank is an intentionally insecure retail banking application: users log in, hold balances, transfer money, request loans, upload profile pictures, manage virtual cards across multiple currencies, pay bills and talk to an AI customer support agent. Every one of those flows carries flaws planted on purpose, from SQL injection in login and biller queries to broken object level authorization (BOLA), broken object property level authorization (BOPLA), mass assignment, path traversal, SSRF via URL-based profile image import, XSS, CSRF and race conditions in transfers, card funding and payment processing. It lives in the application security and DevSecOps ecosystem, tagged with ai-security, apisecurity, application-security, devsecops, penetration-testing and secure-coding.

The concrete problem it solves is the absence of a realistic, safe target. Practitioners otherwise point tools and test scripts at production-like systems they do not own, or at toy endpoints too narrow to exercise API authorization, GraphQL, file handling and LLM prompt behaviour together. vuln-bank replaces the throwaway demo app and the borrowed staging environment with one runnable application that covers a full banking domain — including a public Merchant Payment API and a GraphQL-backed transaction analytics dashboard — so findings, remediation and regression checks can be demonstrated end to end.

Key capabilities

  • Web application flows with planted flaws: authentication and authorization, account balance management, money transfers, loan requests, profile picture upload and transaction history.
  • Banking logic that accepts negative transfer amounts and enforces no transaction limits, exposing race conditions in transfers and balance updates.
  • Virtual card management in USD, GBP, NGN, JPY, EUR, QAR, BTC and ETH, with client-controlled currency conversion during card funding and predictable card number generation.
  • Bill Payments System with SQL injection in biller queries, predictable reference numbers and BOLA in payment history access.
  • Public Merchant Payment API accepting raw card number and CVV, returning API keys in registration and login responses, and missing idempotency, replay protection, payment limits and rate limiting.
  • AI Customer Support Agent backed by a real LLM through the DeepSeek API, with a Mock Mode for offline use — the LLM-specific attack surface.
  • Weak password reset using a 3-digit PIN, plus tokens stored in localStorage, no server-side token invalidation and no session expiration.

Who uses it and how

  • Security engineers run penetration testing and API security assessments against the web, API and GraphQL surfaces, then document findings and fixes.
  • Developers and interns use it for secure code review practice, reading vulnerable source and writing corrected versions of the same flows.
  • QA analysts build reproduction cases for authorization, race condition and input validation defects without touching customer data.
  • DevSecOps practitioners wire it into CI/CD pipelines as a target for security testing automation, confirming that scanners and gates report what they should.
  • Trainers and study groups use the AI Customer Support Agent to cover LLM vulnerabilities alongside conventional web flaws in one environment.

Getting started

The facts supplied here do not include the README's install or run instructions, so no setup command, package name, Docker image or compose file can be stated. The project homepage at https://vulnbank.org is the place to check for the current deployment method.

How it compares

The facts list no paid or proprietary products that vuln-bank replaces, and name no comparable tools. Within this registry it stands alone as a deliberately vulnerable banking target.

When to use it — and when not to

A self-hoster must operate an intentionally insecure application that stores passwords and card details in plaintext and exposes debug output and detailed error messages, so it belongs only in an isolated lab network, never beside real data or credentials. Anyone wanting a hardened reference implementation, a production banking component or a stable library should not pick it, and readers should weigh that the README excerpt provided here is strong on vulnerability inventory but silent on deployment and operational requirements. The project remains actively pushed, has a modest open issue count of 10, and carries a clear MIT licence, which makes it easy to fork and extend for training material.

project readme (upstream, from github) — read inline

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.

image

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)

image

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
  1. 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
  1. 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
  1. Build the Docker image:
docker build -t vuln-bank .
  1. 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
  1. 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
  1. Install required packages:
pip install -r requirements.txt
  1. Create necessary directories:
# On Windows
mkdir static\uploads

# On Linux/Mac
mkdir -p static/uploads

  1. Modify the .env file:

    • Open .env and change DB_HOST from 'db' to 'localhost' for local PostgreSQL connection

  2. Run the application:

# On Windows
python app.py

# On Linux/Mac
python3 app.py

Environment Variables

The .env file is intentionally included in this repository to facilitate easy setup for educational purposes. In a real-world application, you should never commit .env files to version control.

Current environment variables:

DB_NAME=vulnerable_bank
DB_USER=postgres
DB_PASSWORD=postgres
DB_HOST=db  # Change to 'localhost' for local installation
DB_PORT=5432

Database Setup

The application uses PostgreSQL. The database will be automatically initialized when you first run the application, creating:

  • Users table
  • Transactions table
  • Loans table

Accessing the Application

  • Main application: http://localhost:5000
  • API documentation: http://localhost:5000/api/docs
  • GraphQL analytics endpoint: http://localhost:5000/graphql
  • Admin analytics view: available from the admin dashboard after login as an admin user

Common Issues & S

readme truncated — read the full docs on github

Frequently asked questions

Is vuln-bank free to use?

vuln-bank is open source under the MIT licence. There is no licence fee and no seat count — you can self-host it or, where the project offers one, pay a vendor for a managed version instead.

What does vuln-bank do?

A deliberately vulnerable banking application designed for practicing Security Testing of Web App, APIs, AI integrated App and secure code reviews. Features com

What is vuln-bank written in?

vuln-bank is primarily written in HTML. Its source is publicly available at https://github.com/Commando-X/vuln-bank, and it has 933 GitHub stars.