Skip to article frontmatterSkip to article content
Site not loading correctly?

This may be due to an incorrect BASE_URL configuration. See the MyST Documentation for reference.

The Python assert statement itself is not insecure, but its misuse can lead to security vulnerabilities.

Rationale

  1. Assertions are primarily for debugging and development, mainly testing, and NOT for error handling in production code.

When using python -O or python -OO the Python interpreter removes all assert statements from the bytecode.

The special Python __debug__ built-in variable is also set to False when -O is used. So code that checks if __debug__: will also be removed.

This means any crucial checks you rely on for security or data integrity will simply vanish in production when code is run with python -O, leaving your application vulnerable.

  1. Dangers of Side effects in assert Statements in production code:

For AI-generated, Python programs you will see a lot of assert statement warnings. So mind that by default AI generated Python code is not secure.

Preventive Measures

  1. Use assert for testing code and during development only!

assert statements SHOULD be removed when not running in debug mode. This means when invoking the Python command with the -O or -OO options.

  1. Use explicit condition checks and raise proper exceptions (e.g., ValueError, TypeError) for input validation and critical logic.

  2. Never ever use assert in production Python code for checks.

  3. The only safe alternative: Explicit Checks!

For production code, especially when handling external inputs or executing critical logic, always rely on explicit condition checks and robust exception handling.

Example

The following Python example shows how trusting on assert can lead to another behaviour.

"""Example of Python script using the assert statement - which can lead to security issues!"""

def divide_numbers(x,y):
    """
    Divides two numbers.
    Uses an assert statement to ensure the denominator is not zero.
    """
    # Assert that the denominator is not zero.
    # If denominator is 0, an AssertionError will be raised with the given message.
    assert y != 2, "Error: diving is crying!"
    return x / y

print("--- Demonstrating danger of assertions ---")
result = divide_numbers(10, 3)
print(f"Dividing result : {result}")

result2 = 'Error- Dividing is crying!' # A default value to show
try:
    # If run with 'python -O', the 'assert y != 0' line above will be removed.
    # In that scenario, this call will directly raise a ZeroDivisionError,
    # as the assert check won't be present.
    result2 = divide_numbers(10, 2)
except AssertionError as e:
    # This block will be executed if assert is active (without -O)
    print(f"Caught an AssertionError: {e}")
    print('Never divide! Take it all or divide in more parts.')   


print(f"Dividing result - Result should be error, not 5! - : {result2}")

Run this program with:

python assert_example.py

And after that another time with:

python -O assert_example.py

And notice the different outcome.

So this examples shows that if you rely on assert to prevent an AssertionError (or any other critical condition), that check will simply disappear in an optimized environment!

Instead of catching an AssertionError, a program will run differently when python -O is used. And this can and will have consequences for the functional working of a program. But worse it can have severe security consequences. E.g. if asserts are used to validate user input to prevent sql injections e.g.

For robust validation and error handling in production code, always use standard if statements combined with raising appropriate exceptions (like ValueError, TypeError, or custom exceptions) rather than assert.

Discussion

Some aspects of Python security are the subject of long-standing debates and occasional flamewars. Whether using assert statements in production Python code represents a security weakness is particularly contentious.

There are certain edge cases in which using assert in production code can be harmless, even when the code is executed with Python’s -O (optimisation) flag.

Use Case:Type/State Checking in Hot Loops (Performance Tuning):

You use assert to check an internal invariant in a performance-critical loop during development. In production, you deliberately run with python -O to remove the check for speed. You accept that if a bug exists, the program might silently corrupt data instead of crashing. This use case is only safe if the corrupted data cannot affect security-critical decisions. In practice, that is very hard to guarantee. From a security perspective, silent data corruption is often worse than a crash.

Use Case:Detecting Impossible State Corruption (Fail-Fast)

You use assert to check a condition that should literally never be false if your code is bug-free. This is a “programming error detector”, not a runtime guard.

So you could argue for the use of assert in production code to check that code is internally consistent.

However, the truth is that almost every running program requires some form of input from the outside world. Validating all logic from a security perspective would quickly become too complex. So it’s better to be safe than sorry. If you do choose to use assert statements in your production Python code, you should at minimum include a comment (or a marker) explaining why. This way, security reviewers will know that you are aware of the potential impact.

Use Case: Type assurance

Occasionally, a developer knows the type of a variable, but a type checker or linter (such as mypy, basedpyright, or pyright) cannot infer it correctly. This is frustrating because you are certain the code is correct.

You can resolve this by using:

assert isinstance(var, SomeType)

This is not necessarily bad in production:

ConcernClarification
Performance overheadassert statements can be disabled globally with the -O (optimise) flag. In many production environments, this flag is not used, so assert remains active.
Risk of AssertionErrorIf the assertion fails, the program crashes. However, if you are absolutely certain the type is correct, this crash will never happen. The assert serves as a developer assertion and a type narrowing hint.
Alternative approachesYou could use cast(SomeType, var) from typing, but cast does nothing at runtime. assert isinstance(...) provides both runtime checking (helpful for debugging) and type narrowing for static analysis.

Only use this pattern when:

Example:

def process_data(data: dict[str, object]) -> list[int]:
    # The linter cannot infer that 'values' is always a list of ints,
    # but you know from the API contract that this is true.
    values = data.get("values", [])
    
    # This assert helps mypy/pyright understand the type,
    # and provides a runtime sanity check.
    assert isinstance(values, list)
    
    # Now the linter knows 'values' is a list
    return [int(x) for x in values]

But still:

from typing import cast

# No runtime check, but helps the type checker
values = cast(list, data.get("values", []))

Or like stated in the Python manual, just do:

def greet(name: str) -> None:
    assert_type(name, str)  # OK, inferred type of `name` is `str`
    assert_type(name, int)  # type checker error

More information

Python Security Handbook
Dangerous Python Constructs
Python Security Handbook
Input Statement