Exposing Sensitive User Data

Introduction

Welcome to the lesson on exposing sensitive user data, a common vulnerability within the broader category of "Broken Access Control." In this lesson, we'll explore how web applications can inadvertently leak sensitive information through API endpoints. This often happens when an application returns more data than necessary, failing to properly control who has access to what information. Understanding what constitutes sensitive data and how to prevent its exposure is crucial for building secure applications, maintaining user trust, and complying with data protection regulations. Let's dive in and learn how to identify and fix these vulnerabilities! 🔍

Understanding Sensitive User Data

Sensitive user data is any information that, if disclosed, could cause harm to an individual or organization. This type of data requires the highest level of protection. While it might seem obvious, developers sometimes overlook the full scope of what's considered sensitive. Key examples include: Passwords : Even in their hashed form, passwords are a critical secret. Exposing them allows attackers to perform offline cracking attempts, which can lead to account takeovers. Personal Identification Numbers (PINs) : Similar to passwords, these are used for identity verification and must be kept confidential. Financial Information : This includes credit card numbers, bank account details, and transaction histories. Exposure can lead to direct financial theft. Personally Identifiable Information (PII) : This includes names, addresses, phone numbers, and government-issued IDs. This data can be used for identity theft and other malicious activities. Protecting this data isn't just a best practice; it's often a legal requirement. In the context of access control, the vulnerability arises when an application fails to restrict access to this data, making it available to unauthorized users or even unauthenticated visitors.

The Vulnerable Code

Let's examine a code snippet from a Python FastAPI application. This endpoint is designed to fetch and return a user's profile details. However, it contains a critical flaw that exposes sensitive data. Python@router.get("/details") async def get_details(db: AsyncSession = Depends(get_db)): # for demo, assume user with id=1 result = await db.execute(select(User).where(User.id == 1)) user = result.scalar_one_or_none() if not user: raise HTTPException(status_code=404, detail="User not found") return { "id": user.id, "username": user.username, "password": user.password, # BAD: exposing hash "role": user.role.value, }@router.get("/details") async def get_details(db: AsyncSession = Depends(get_db)): # for demo, assume user with id=1 result = await db.execute(select(User).where(User.id == 1)) user = result.scalar_one_or_none() if not user: raise HTTPException(status_code=404, detail="User not found") return { "id": user.id, "username": user.username, "password": user.password, # BAD: exposing hash "role": user.role.value, } The vulnerability lies in the return statement. The code retrieves a User object from the database and then serializes it into a JSON response. In doing so, it directly includes the user.password field. While the password stored in the database is (hopefully) hashed, exposing this hash is still a major security risk. An attacker who obtains this hash can attempt to crack it offline without fear of being locked out, potentially revealing the user's original password. It's worth noting that while exposing a hash is a serious flaw, some applications commit an even greater sin: storing and exposing passwords in plaintext. This is a critical vulnerability that provides an attacker with direct access to user accounts without any effort.

Join the 1M+ learners on CodeSignal

Be a part of our community of 1M+ users who develop and demonstrate their skills on CodeSignal

Step 1: Ensure Password Hashing During Registration

The first line of defense is to ensure that we are never storing plaintext passwords in our database. Let's look at a secure registration endpoint that correctly hashes passwords using the bcrypt library before saving them.

Python

@router.post("/register")
async def register(request: Request, db: AsyncSession = Depends(get_db)):
    data = await request.json()
    username = data.get('username')
    password = data.get('password')
    role = data.get('role', 'user')
    
    # Ensure role is either 'admin' or 'user'
    user_role = Role.ADMIN if role == 'admin' else Role.USER
    
    result = await db.execute(select(User).where(User.username == username))
    existing_user = result.scalar_one_or_none()
    
    if existing_user:
        raise HTTPException(status_code=400, detail="Username already exists")
    
    # Hash the password before saving in the database!
    hashed_password = bcrypt.hashpw(password.encode(), bcrypt.gensalt()).decode('utf-8')
    user = User(username=username, password=hashed_password, role=user_role)
    
    db.add(user)
    await db.commit()
    await db.refresh(user)
    
    return {"message": "User registered successfully", "userId": user.id}

@router.post("/register")
async def register(request: Request, db: AsyncSession = Depends(get_db)):
    data = await request.json()
    username = data.get('username')
    password = data.get('password')
    role = data.get('role', 'user')
    
    # Ensure role is either 'admin' or 'user'
    user_role = Role.ADMIN if role == 'admin' else Role.USER
    
    result = await db.execute(select(User).where(User.username == username))
    existing_user = result.scalar_one_or_none()
    
    if existing_user:
        raise HTTPException(status_code=400, detail="Username already exists")
    
    # Hash the password before saving in the database!
    hashed_password = bcrypt.hashpw(password.encode(), bcrypt.gensalt()).decode('utf-8')
    user = User(username=username, password=hashed_password, role=user_role)
    
    db.add(user)
    await db.commit()
    await db.refresh(user)
    
    return {"message": "User registered successfully", "userId": user.id}

In this code, the key line is bcrypt.hashpw(password.encode(), bcrypt.gensalt()). Let's break it down:

password.encode(): Converts the user's password string into bytes, which is required by the hashing function.
bcrypt.gensalt(): Generates a unique "salt." A salt is a random string that is combined with the password before hashing. This ensures that even if two users have the same password, their stored hashes will be different, preventing rainbow table attacks.
bcrypt.hashpw(...): Performs the hashing operation.
.decode('utf-8'): Converts the resulting hash bytes back into a string for storage in the database.

With this implementation, we are securely storing user credentials. Now, let's fix the data exposure in our /details endpoint.

Step 2: Using Pydantic Response Models for Secure Responses

Now for the main fix: we must prevent the API from leaking the password hash. FastAPI provides a powerful feature called response models using Pydantic schemas. This approach enforces response filtering at the framework level, making it much harder to accidentally expose sensitive data.

First, we define a Pydantic schema that specifies exactly which fields should be included in the response:

Python

from pydantic import BaseModel

class UserResponse(BaseModel):
    id: int
    username: str
    role: str
    
    class Config:
        from_attributes = True  # Allows Pydantic to read from SQLAlchemy ORM models

from pydantic import BaseModel

class UserResponse(BaseModel):
    id: int
    username: str
    role: str
    
    class Config:
        from_attributes = True  # Allows Pydantic to read from SQLAlchemy ORM models

This UserResponse class acts as a contract: it explicitly lists the fields that are safe to expose. Notice that password is not included in this schema.

Now we apply this response model to our endpoint:

Python

@router.get("/details", response_model=UserResponse)
async def get_details_secure(request: Request, db: AsyncSession = Depends(get_db)):
    # require auth; derive userId from token
    authz = request.headers.get("authorization")
    if not authz:
        raise HTTPException(status_code=401, detail="Authentication required")
    token = authz.split(" ")[1] if authz.startswith("Bearer ") else authz
    try:
        decoded = jwt.decode(token, JWT_SECRET_KEY, algorithms=["HS256"])
        user_id = decoded.get("userId")
    except JWTError:
        raise HTTPException(status_code=401, detail="Invalid token")

    result = await db.execute(select(User).where(User.id == user_id))
    user = result.scalar_one_or_none()
    if not user:
        raise HTTPException(status_code=404, detail="User not found")

    # FastAPI automatically filters the response to match UserResponse schema
    return user

@router.get("/details", response_model=UserResponse)
async def get_details_secure(request: Request, db: AsyncSession = Depends(get_db)):
    # require auth; derive userId from token
    authz = request.headers.get("authorization")
    if not authz:
        raise HTTPException(status_code=401, detail="Authentication required")
    token = authz.split(" ")[1] if authz.startswith("Bearer ") else authz
    try:
        decoded = jwt.decode(token, JWT_SECRET_KEY, algorithms=["HS256"])
        user_id = decoded.get("userId")
    except JWTError:
        raise HTTPException(status_code=401, detail="Invalid token")

    result = await db.execute(select(User).where(User.id == user_id))
    user = result.scalar_one_or_none()
    if not user:
        raise HTTPException(status_code=404, detail="User not found")

    # FastAPI automatically filters the response to match UserResponse schema
    return user

There are several key improvements here:

Authentication: The endpoint now requires a valid JSON Web Token (JWT) for authentication. It extracts the user_id from the token to fetch the correct user's data, preventing one user from accessing another's details.
Automatic Response Filtering: By adding response_model=UserResponse to the decorator, FastAPI automatically filters the response. Even though we return the entire user object, FastAPI only includes the fields defined in UserResponse. The password field is never sent to the client.
Framework-Level Enforcement: This isn't just a convention - it's enforced by the framework. Even if a developer accidentally tries to return sensitive data, FastAPI will exclude it based on the schema.
Type Safety: Pydantic validates that the returned data matches the expected types, catching potential bugs early.
Self-Documenting: The API documentation (OpenAPI/Swagger) automatically reflects the correct response structure, making it clear to developers what data is returned.

This "allow-list" approach is much safer than trying to manually exclude sensitive fields, as you might forget one. As your User model evolves and gains new fields, you must explicitly add them to UserResponse for them to be exposed, rather than having them automatically leak.

Introduction

Understanding Sensitive User Data

The Vulnerable Code

Join the 1M+ learners on CodeSignal

Exploiting the Vulnerability

Understanding Password Hashing

Step 1: Ensure Password Hashing During Registration

Step 2: Using Pydantic Response Models for Secure Responses

Real-World Examples and Impact

Conclusion and Next Steps