Security and Authentication for Fintech Applications

Security Is Not Optional in Finance

Financial applications are among the highest-value targets for attackers. They handle money, store sensitive personal data, and connect to payment systems and banking infrastructure. A security breach in a fintech application can mean direct financial losses, regulatory fines, loss of customer trust, and in severe cases, criminal liability.

Every developer working in finance needs a baseline understanding of security. You do not need to be a security specialist, but you need to know enough to avoid the common mistakes that cause breaches.

---

Authentication: Proving Who You Are

Authentication verifies identity — confirming that the person or system making a request is who they claim to be.

Password Hashing

Never store passwords in plain text. Never. Use a slow, salted hashing algorithm designed for passwords:

import bcrypt

def hash_password(password: str) -> bytes:
    salt = bcrypt.gensalt(rounds=12)  # Work factor of 12
    return bcrypt.hashpw(password.encode(), salt)

def verify_password(password: str, hashed: bytes) -> bool:
    return bcrypt.checkpw(password.encode(), hashed)

# Store the hash, never the password
stored_hash = hash_password("user_password_123")
is_valid = verify_password("user_password_123", stored_hash)  # True

The rounds parameter controls how slow the hashing is. Higher is more secure but slower. 12 is a common production value — it takes about 250ms to hash, which is imperceptible to users but makes brute-force attacks impractical.

JWTs: Token-Based Authentication

JSON Web Tokens are the standard for API authentication. The server creates a signed token after login; the client includes it in subsequent requests.

import jwt
from datetime import datetime, timedelta

SECRET_KEY = "your-secret-key"  # In practice, from environment variables

def create_token(user_id: str, role: str) -> str:
    payload = {
        "sub": user_id,
        "role": role,
        "iat": datetime.utcnow(),
        "exp": datetime.utcnow() + timedelta(hours=1),
    }
    return jwt.encode(payload, SECRET_KEY, algorithm="HS256")

def verify_token(token: str) -> dict:
    try:
        return jwt.decode(token, SECRET_KEY, algorithms=["HS256"])
    except jwt.ExpiredSignatureError:
        raise AuthenticationError("Token expired")
    except jwt.InvalidTokenError:
        raise AuthenticationError("Invalid token")

# Client includes token in requests
# Authorization: Bearer eyJhbGciOiJIUzI1NiIs...

Multi-Factor Authentication (MFA)

For financial applications, MFA is increasingly mandatory. Something you know (password) plus something you have (phone, hardware key). TOTP (Time-based One-Time Password) is the most common implementation — the same standard behind Google Authenticator and Authy.

OAuth 2.0 and OpenID Connect

For applications that need to integrate with third-party services (bank APIs, market data providers), OAuth 2.0 is the standard. It allows users to grant limited access without sharing their credentials. OpenID Connect adds identity verification on top of OAuth.

---

Authorisation: Controlling What You Can Do

Authentication says "you are who you claim to be." Authorisation says "here is what you are allowed to do." These are separate concerns.

Role-Based Access Control (RBAC)

The most common model: users are assigned roles, roles have permissions.

PERMISSIONS = {
    "trader": ["view_positions", "submit_orders", "view_pnl"],
    "risk_manager": ["view_positions", "view_pnl", "view_risk", "set_limits"],
    "admin": ["view_positions", "submit_orders", "view_pnl", "view_risk",
              "set_limits", "manage_users", "view_audit"],
    "read_only": ["view_positions", "view_pnl"],
}

def check_permission(user_role: str, required_permission: str) -> bool:
    return required_permission in PERMISSIONS.get(user_role, [])

# In an API endpoint
@app.post("/api/v1/orders")
def submit_order(order: OrderRequest, user: User = Depends(get_current_user)):
    if not check_permission(user.role, "submit_orders"):
        raise HTTPException(403, "Insufficient permissions")
    return execute_order(order)

Principle of Least Privilege

Every user, service, and system component should have the minimum permissions needed to do its job — and nothing more. A reporting service does not need write access to the trading database. A junior analyst does not need admin access to the risk system.

This applies at every level: application permissions, database access, cloud IAM roles, and network access rules.

---

Encryption

In Transit

All network communication should use TLS (HTTPS). In 2024, there is no excuse for unencrypted traffic. This protects against eavesdropping and man-in-the-middle attacks on the network.

At Rest

Sensitive data stored in databases and files should be encrypted. Cloud providers offer transparent encryption for storage services — enable it by default. For particularly sensitive data (PII, account numbers), consider application-level encryption on top.

from cryptography.fernet import Fernet

# Generate and securely store the key
key = Fernet.generate_key()
cipher = Fernet(key)

# Encrypt sensitive data before storing
account_number = "1234567890"
encrypted = cipher.encrypt(account_number.encode())
# Store 'encrypted' in the database

# Decrypt when needed
decrypted = cipher.decrypt(encrypted).decode()

---

Common Vulnerabilities

SQL Injection

The most basic and still one of the most dangerous vulnerabilities:

# VULNERABLE: user input directly in SQL
query = f"SELECT * FROM users WHERE username = '{username}'"

# SAFE: parameterised query
cursor.execute("SELECT * FROM users WHERE username = %s", (username,))

If you use an ORM or a query builder, SQL injection is largely handled for you. But anytime you write raw SQL, use parameterised queries — always.

Cross-Site Scripting (XSS)

For web applications, XSS occurs when user input is rendered as HTML without sanitisation. An attacker could inject JavaScript that steals session tokens or redirects to phishing sites.

Insecure Dependencies

Third-party libraries can contain vulnerabilities. Use dependency scanning tools (Snyk, Dependabot, Safety for Python) to catch known issues:

# Check Python dependencies for known vulnerabilities
pip install safety
safety check

# Or with pip-audit
pip install pip-audit
pip-audit

Secrets Management

Never hardcode API keys, database passwords, or encryption keys in source code. Use environment variables for simple cases and dedicated secret management tools (AWS Secrets Manager, HashiCorp Vault) for production.

import os

# Good: from environment
database_url = os.environ["DATABASE_URL"]
api_key = os.environ["API_KEY"]

# Bad: hardcoded
database_url = "postgresql://admin:password123@db.example.com/trading"

---

Security in the Development Process

Security is not something you bolt on at the end. Integrate it into your SDLC:

1. Threat modelling — before building, ask "what could go wrong?"
2. Secure code review — include security as a checklist item in code reviews
3. Dependency scanning — automated checks in CI/CD
4. Penetration testing — periodic testing by security specialists
5. Incident response plan — know what to do when (not if) something happens

---

Audit and Compliance

Financial applications must maintain comprehensive audit trails:

import logging

audit_logger = logging.getLogger("audit")

def submit_order(order, user):
    audit_logger.info(
        "ORDER_SUBMITTED",
        extra={
            "user_id": user.id,
            "order_id": order.id,
            "symbol": order.symbol,
            "quantity": order.quantity,
            "price": order.price,
            "timestamp": datetime.utcnow().isoformat(),
            "ip_address": request.client_ip,
        }
    )
    # ... process order ...

Every significant action — logins, data access, configuration changes, order submissions — should be logged with enough context to answer: who did what, when, from where, and why? This is not just good practice — in many jurisdictions, it is a regulatory requirement.

Security is a deep field, and this guide covers the fundamentals. The most important thing is the mindset: assume your system will be attacked, design accordingly, and verify continuously.