DEV Community: Egor

This 3-Line Python Mistake Can Disable Your Entire API Authentication

Egor — Tue, 13 Oct 2026 18:24:18 +0000

Ever written a security check that looked perfectly reasonable... until you realized it could let everyone in?

Here's a tiny Python mistake that can turn an API key check into an authentication bypass.

No complicated exploit. No special tools.

Just a missing environment variable.

The innocent-looking code

Imagine a FastAPI application protecting an internal endpoint with an API key.

import os

from fastapi import FastAPI, Header, HTTPException

app = FastAPI()

API_KEY = os.getenv("API_KEY", "")


@app.get("/admin")
async def admin(x_api_key: str = Header(default="")):
    if API_KEY and x_api_key != API_KEY:
        raise HTTPException(status_code=401)

    return {"message": "Welcome, admin!"}

Looks reasonable, right?

We read the secret from an environment variable, compare it against the incoming header, and reject unauthorized requests.

Except there's one pretty serious problem.

What happens if API_KEY isn't configured?

The bug hiding in plain sight

Look closely at this condition:

if API_KEY and x_api_key != API_KEY:

Python's and operator short-circuits.

When API_KEY is an empty string, the first condition is false.

So Python never evaluates the comparison.

And the application never raises the authentication error.

That means this request:

curl http://localhost:8000/admin

Can return:

{
  "message": "Welcome, admin!"
}

No API key required.

The authentication mechanism has silently failed open.

And the scariest part?

The application can start successfully, pass basic health checks, and expose the protected endpoint without an obvious error.

Fail-open vs. fail-closed

This is the difference between two important security concepts.

Fail-open: When something goes wrong, access is allowed.

Fail-closed: When something goes wrong, access is denied.

Authentication should generally fail closed.

If your application cannot load its authentication secret, it should not simply allow requests through.

The absence of a security configuration should be treated as an error, not permission.

Fix #1: Reject missing configuration

Instead of silently providing an empty default:

API_KEY = os.getenv("API_KEY", "")

Require the environment variable:

API_KEY = os.environ["API_KEY"]

if not API_KEY.strip():
    raise RuntimeError("API_KEY must not be empty")

Now the application fails during startup if the API key is missing or blank.

This is a much safer failure mode.

An unavailable service is inconvenient.

An accidentally unprotected service can be disastrous.

Fix #2: Compare secrets safely

For secret comparisons, Python provides hmac.compare_digest().

Here's a better implementation:

import os
import hmac

from fastapi import FastAPI, Header, HTTPException

app = FastAPI()

API_KEY = os.environ["API_KEY"]

if not API_KEY.strip():
    raise RuntimeError("API_KEY must not be empty")


@app.get("/admin")
async def admin(x_api_key: str | None = Header(default=None)):
    if x_api_key is None or not hmac.compare_digest(
        x_api_key, API_KEY
    ):
        raise HTTPException(
            status_code=401,
            detail="Unauthorized",
        )

    return {"message": "Welcome, admin!"}

This version improves several things:

Missing configuration prevents successful startup.
Missing credentials are rejected.
Incorrect credentials are rejected.
Secret comparison uses a function designed to avoid content-dependent short-circuit comparisons.

Constant-time comparison is useful defense in depth, but it doesn't replace TLS, proper secret management, access controls, or rate limiting.

Fix #3: Test the failure, not just the success

Developers often test authentication with a valid API key.

Maybe they also test an incorrect key.

But how often do they test a missing configuration?

Here's a minimal example of a regression test for the original logic:

def vulnerable_check(expected: str, provided: str) -> bool:
    if expected and provided != expected:
        return False

    return True


def test_missing_secret_must_not_grant_access():
    assert vulnerable_check("", "") is False

This test fails against the vulnerable implementation.

And that's exactly what we want it to reveal.

The corrected standalone version:

import hmac


def secure_check(expected: str, provided: str) -> bool:
    if not expected.strip():
        return False

    return hmac.compare_digest(expected, provided)


def test_missing_secret():
    assert secure_check("", "") is False


def test_wrong_secret():
    assert secure_check("secret123", "wrong") is False


def test_correct_secret():
    assert secure_check("secret123", "secret123") is True

These tests cover the comparison logic. An actual FastAPI application should also have integration tests proving that missing configuration prevents startup and unauthenticated requests return HTTP 401.

The bigger lesson

This isn't really about FastAPI.

The same mistake can appear in:

Django applications
Flask APIs
Microservices
Webhook authentication
Internal admin dashboards
Background worker APIs

And it's not limited to API keys.

Any security feature that depends on optional configuration deserves a careful review.

For example:

if SECRET and validate_token(token):
    ...

Or:

if ENABLE_AUTH:
    check_permissions()

What happens when those values are missing, empty, or incorrectly configured?

The important question isn't just:

"Does authentication work when everything is configured correctly?"

It's also:

"What happens when the security configuration breaks?"

Final thoughts

Not every serious security bug requires complex cryptography or sophisticated attacks.

Sometimes all it takes is an empty string and one if statement.

Three things worth remembering:

Never silently disable authentication because a secret is missing.
Validate critical security configuration during application startup.
Write tests for failure conditions, not only successful requests.

Secure software isn't only about handling the expected path correctly.

It's also about making sure the unexpected path doesn't become an open door.

Have you ever discovered a security bug caused by a seemingly harmless default value?

Share it in the comments. I'd love to hear about it.

If you enjoy Python, backend architecture, and application security, feel free to connect:

GitHub: https://github.com/coffee1337

Portfolio: https://coffee1337.github.io/

Your FastAPI App Is Async. So Why Is It Still Slow?

Egor — Tue, 13 Oct 2026 10:03:12 +0000

Your FastAPI App Is Async. So Why Is It Still Slow? 🐍

Understanding the difference between writing async code and building an actually concurrent Python backend.

You built your API with FastAPI.

You used async def everywhere.

You even added await to your database calls.

So why does one slow request still seem to affect everything else?

Here's something that surprises a lot of Python developers:

Using async doesn't automatically make your application non-blocking.

And in some cases, a perfectly valid asynchronous endpoint can make your application perform worse than a regular synchronous one.

Let's explore why.

1. The `async def` Illusion

Consider this FastAPI endpoint:

from fastapi import FastAPI
import time

app = FastAPI()

@app.get("/slow")
async def slow_endpoint():
    time.sleep(5)
    return {"message": "Done"}

At first glance, everything looks fine.

The endpoint uses async def, just like many FastAPI examples.

But there's a problem:

time.sleep(5)

This call blocks the thread running the event loop.

While it executes, the event loop cannot make progress on other coroutines running on that same thread.

If multiple requests arrive, they can end up waiting for each other.

The endpoint is declared asynchronous, but its implementation blocks asynchronous execution.

The fix

Replace the blocking call with an asynchronous one:

import asyncio
from fastapi import FastAPI

app = FastAPI()

@app.get("/slow")
async def slow_endpoint():
    await asyncio.sleep(5)
    return {"message": "Done"}

Now something important changes.

When Python reaches:

await asyncio.sleep(5)

The coroutine suspends and gives control back to the event loop.

Other requests can make progress while the first one waits.

This is the foundation of asynchronous programming.

2. Concurrency Is Not Parallelism

This distinction matters.

Concurrency means multiple tasks can make progress during overlapping periods.

Parallelism means multiple tasks actually execute at the same time, typically on different CPU cores.

AsyncIO is primarily about cooperative concurrency.

Imagine three API requests, each waiting two seconds for an external service.

With blocking operations, a single-threaded execution model might look like this:

Request A: [----2s----]
Request B:             [----2s----]
Request C:                         [----2s----]

Total: ~6 seconds

With asynchronous waiting:

Request A: [----2s----]
Request B: [----2s----]
Request C: [----2s----]

Total: ~2 seconds

These are simplified timelines, not benchmark results. Real application performance also depends on worker configuration, connection pools, infrastructure, and external services.

The key idea is that asynchronous tasks can overlap their waiting time.

But what happens when the work is CPU-intensive?

That's where things get interesting.

3. AsyncIO Won't Magically Speed Up CPU-Heavy Code

Imagine your API needs to perform an expensive calculation.

def expensive_calculation():
    total = 0

    for i in range(30_000_000):
        total += i * i

    return total

Now put it inside an async endpoint:

@app.get("/calculate")
async def calculate():
    result = expensive_calculation()
    return {"result": result}

This is still blocking.

Why?

Because expensive_calculation() is regular Python code that continuously uses CPU time.

There is no asynchronous waiting point where the coroutine can yield control.

Adding async to the endpoint doesn't transform CPU-bound work into non-blocking work.

A better approach

For CPU-intensive operations, you may need:

A separate process
A process pool
A background job system
A dedicated worker service

For example, Python's ProcessPoolExecutor can execute work in separate processes.

import asyncio
from concurrent.futures import ProcessPoolExecutor

from fastapi import FastAPI

app = FastAPI()

pool = ProcessPoolExecutor(max_workers=2)


def expensive_calculation():
    return sum(i * i for i in range(30_000_000))


@app.get("/calculate")
async def calculate():
    loop = asyncio.get_running_loop()

    result = await loop.run_in_executor(
        pool,
        expensive_calculation,
    )

    return {"result": result}

The CPU-heavy function runs outside the event-loop process, allowing the event loop to continue serving other requests.

This is a simplified example. In a real deployment, the process pool should be managed as part of the application's lifecycle, and worker counts should be chosen based on available resources.

For expensive or long-running jobs, returning a task ID and processing work asynchronously in a dedicated worker is often a better API design.

4. The Hidden Problem: Synchronous HTTP Clients

Here's another common mistake.

import requests

@app.get("/users")
async def get_users():
    response = requests.get(
        "https://jsonplaceholder.typicode.com/users",
        timeout=10,
    )

    return response.json()

The requests library performs synchronous HTTP operations.

So even though the endpoint is asynchronous, the outgoing request blocks the event-loop thread until it finishes.

A better choice for async endpoints is an asynchronous HTTP client.

For example, HTTPX:

import httpx

@app.get("/users")
async def get_users():
    async with httpx.AsyncClient(
        timeout=10.0
    ) as client:
        response = await client.get(
            "https://jsonplaceholder.typicode.com/users"
        )

        response.raise_for_status()

        return response.json()

Now the endpoint can yield control while waiting for the external API.

For production applications, it's usually better to reuse an AsyncClient rather than create a new one for every request.

Reusing the client allows connection pooling and reduces unnecessary connection overhead.

5. What About Database Queries?

The same principle applies to databases.

An asynchronous endpoint doesn't automatically make database access asynchronous.

For example:

@app.get("/users/{user_id}")
async def get_user(user_id: int):
    user = sync_db_query(user_id)
    return user

If sync_db_query() blocks, your event loop is blocked.

With SQLAlchemy's asynchronous API, database operations can look like this:

from sqlalchemy import select
from sqlalchemy.ext.asyncio import AsyncSession


async def get_user(
    session: AsyncSession,
    user_id: int,
):
    result = await session.execute(
        select(User).where(User.id == user_id)
    )

    return result.scalar_one_or_none()

This example assumes that User is a defined SQLAlchemy model and the session uses an asynchronous database driver.

However, there's another important detail:

Async database access doesn't make slow SQL queries fast.

If a query takes three seconds because of missing indexes, inefficient joins, or a poor execution plan, adding await won't fix that.

Async improves how your application handles waiting.

Database optimization improves how quickly that waiting ends.

Both matter.

6. More Concurrency Can Actually Make Things Worse

Suppose your API suddenly receives 1,000 requests.

Each request needs a database connection.

Your PostgreSQL connection pool supports 20 simultaneous connections.

What happens?

The application cannot magically execute 1,000 database queries concurrently using only 20 available connections.

Some requests must wait for a connection to become available.

And increasing the pool size isn't always the right answer.

Too many connections can overload the database and reduce overall throughput.

This is where concepts like backpressure, rate limiting, bounded concurrency, and connection pooling become important.

For example, you can limit concurrent operations using an asyncio.Semaphore.

import asyncio

semaphore = asyncio.Semaphore(10)


async def fetch_external_data(client, url):
    async with semaphore:
        response = await client.get(url)
        response.raise_for_status()
        return response.json()

This example limits calls using that semaphore to ten concurrent operations within the process.

It doesn't create a global limit across multiple application workers or servers.

That's an important difference in distributed deployments.

7. How to Know If Your API Is Actually Fast

One of the biggest mistakes in backend development is optimizing code without measuring anything.

An endpoint taking 100 milliseconds doesn't tell you much by itself.

You should also consider:

Latency

How long does an individual request take?

Throughput

How many requests can your application handle per second?

P95 and P99 latency

How long do the slowest 5% and 1% of requests take?

Error rate

Does your application start returning errors under load?

Resource utilization

Are you constrained by CPU, memory, database connections, or an external API?

Tools such as Locust, k6, and Prometheus can help you investigate these questions.

The important part is testing under realistic workloads.

A backend that responds quickly to one request may behave completely differently when hundreds of users arrive simultaneously.

8. A Practical Rule for FastAPI Developers

Here's a mental model worth remembering:

Workload	Common approach
Async HTTP requests	`httpx.AsyncClient`
Async database operations	Async driver + SQLAlchemy AsyncSession
Waiting for timers	`asyncio.sleep()`
Blocking I/O library	Sync endpoint or thread pool
CPU-intensive calculation	Process pool or dedicated worker
Long-running background job	Job queue + worker
High-volume external API calls	Connection pooling + bounded concurrency

These are guidelines, not universal rules.

For example, FastAPI can execute regular def path operations in a thread pool, which is useful when integrating synchronous libraries.

But thread pools have limits, too.

The goal isn't to use async everywhere.

The goal is to choose the right execution model for your workload.

Final Thoughts

AsyncIO is powerful, but it's easy to misunderstand.

A Python application doesn't become scalable simply because its functions contain async and await.

The real performance improvements come from understanding:

What blocks the event loop
Where your application spends time waiting
Which operations are CPU-bound
How database and HTTP connection pools behave
When concurrency needs to be limited
How your application performs under realistic load

The best backend architecture isn't the one with the most asynchronous code.

It's the one that understands where the bottlenecks are.

And sometimes, replacing a single blocking function can make a bigger difference than rewriting an entire service.

💬 Let's Discuss

What's the most unexpected performance bottleneck you've encountered in a Python backend?

Was it a blocking library, a database query, an external API, or something completely different?

I'd love to hear your experience in the comments.

Interested in Python backend development, FastAPI, and building scalable applications?

GitHub: https://github.com/coffee1337
Portfolio: https://coffee1337.github.io/

Thanks for reading! 🚀

AI Python Mentor

Egor — Mon, 12 Oct 2026 15:01:18 +0000

Building an AI-Powered Python Learning Platform with FastAPI, Next.js, and RAG

Building an AI-powered application is relatively easy when all you need is a chat interface connected to an LLM API.

Building a complete learning platform around that AI is a different challenge.

I wanted to explore how to combine a structured curriculum, practical programming exercises, personalized learning, and an AI tutor into a single full-stack system.

That's how AI Python Mentor started.

In this article, I'll walk through the architecture, technology choices, AI integration, and some of the engineering challenges behind the project.

GitHub: https://github.com/coffee1337/ai-python-mentor

The Idea

AI Python Mentor is a full-stack platform designed to help users learn Python and backend development.

Instead of simply providing AI-generated explanations, the application combines several learning mechanisms:

A structured curriculum covering Python and backend concepts
Programming exercises and knowledge checks
An AI tutor with access to lesson context
Personalized learning roadmaps
Progress tracking and spaced repetition
Career-oriented skill gap analysis
Practical portfolio projects

The goal is to build an environment where AI supports structured learning rather than replacing it.

Technology Stack

The application uses:

Backend

Python 3.12
FastAPI
PostgreSQL
SQLAlchemy and Alembic
Pydantic
AsyncIO

Frontend

Next.js 15
React 19
TypeScript

LLM Gateway
Retrieval-Augmented Generation (RAG)
Lesson-based knowledge indexing
Token usage and cost accounting

Infrastructure

Docker and Docker Compose
GitHub Actions
Background workers
Database migrations

I chose FastAPI because it provides a solid foundation for asynchronous API development, explicit validation, and modular backend design.

PostgreSQL handles relational data, while SQLAlchemy and Alembic manage database access and schema evolution.

System Architecture

The application follows a modular monolith approach.

The core API is responsible for authentication, learning progress, lessons, exercises, and integrations.

Specialized tasks can be handled by separate processes.

                    Browser
                       |
                       v
                 Next.js Frontend
                       |
                       v
                  FastAPI API
                       |
        +--------------+--------------+
        |              |              |
        v              v              v
    PostgreSQL     AI Gateway     Background
                       + RAG        Workers
        |
        +---- Learning Progress
        +---- User Sessions
        +---- Exercise Attempts
        +---- AI Usage Records

Separate execution architecture:
    Execution Dispatcher
              |
              v
       Isolated Python Runner

One of my architectural goals was to keep core learning features independent of the availability of external AI services.

For example, if the AI Gateway is unavailable, users should still be able to access lessons and other non-AI functionality.

This separation makes the application easier to maintain and evolve.

Building an AI Tutor with RAG

A general-purpose LLM can explain Python concepts, but it doesn't automatically know which lesson a student is studying or which version of the material is currently published.

That's where Retrieval-Augmented Generation becomes useful.

AI Python Mentor uses a local knowledge index built from immutable snapshots of published lesson content.

The basic flow is:

Student asks a question
          |
          v
Identify current lesson
          |
          v
Retrieve relevant lesson context
          |
          v
Build LLM request
          |
          v
Generate contextual explanation
          |
          v
Track usage and cost

By retrieving context from the learning materials, the AI tutor can ground its explanations in the content the student is actually studying.

This is particularly important for educational applications, where a technically correct answer may still be inappropriate for the learner's current level.

The platform also tracks AI usage and costs.

This is an important consideration when building products that rely on paid LLM APIs.

Handling Python Code Execution

Another challenge is supporting practical programming exercises.

Users submit Python solutions following a simple contract:

def solve(payload):
    # User implementation
    ...

Exercises can define public examples and hidden tests, while the platform stores submissions and attempt history.

However, executing untrusted Python code directly inside the main API would introduce significant security risks.

For that reason, the system separates execution dispatching from the primary application and defines a dedicated Python Runner architecture.

The production execution model is designed around isolation and resource restrictions, including container or sandbox boundaries.

Important: Untrusted code execution is disabled by default. The production Runner still requires the appropriate isolated deployment and security configuration.

The key design decision is simple: the main web API should never become the execution environment for arbitrary user code.

Authentication and Security

The backend includes several account security features:

Cookie-based sessions
Argon2 password hashing
CSRF protection
Email confirmation and password recovery
Session revocation
Account export and deletion
Administrative audit logging

These features are important because real applications require much more than a working login endpoint.

For production deployments, secure cookies and HTTPS are also required.

Background Processing

Not every operation should run directly inside an HTTP request.

The architecture includes background processing for workloads such as notifications and execution dispatching.

Separating those workloads helps keep request handling responsive and makes longer-running operations easier to manage.

Testing and CI

The repository includes automated checks for backend functionality, database migrations, frontend builds, worker logic, and browser flows.

GitHub Actions helps validate changes across these areas.

I also added support for native Windows development without requiring Docker for every local workflow.

That was useful because it made the development environment more accessible while keeping Docker-based deployment options available.

Current Status

AI Python Mentor is still under active development.

The core learning platform, backend, AI integration, database layer, and CI infrastructure have been implemented.

Current work focuses on product polish, learning content quality, AI evaluation, and production deployment.

I prefer being transparent about this: having a production-oriented architecture does not mean every planned production component has already been deployed.

What I Learned

This project reinforced several engineering lessons:

1. AI should be a component, not the entire architecture.

A useful AI product still needs reliable authentication, data models, application logic, and operational safeguards.

2. Structured context matters.

RAG is particularly valuable when answers should reflect specific, versioned learning materials.

3. Security boundaries should be designed early.

This is especially important when an application accepts executable code from users.

4. Operational concerns are product features.

Usage quotas, cost tracking, background jobs, and testing all contribute to the long-term viability of an AI application.

What's Next?

My next priorities include improving AI evaluation, polishing the user experience, refining educational content, and preparing the infrastructure for production deployment.

You can explore the code and architecture here: