What are Injection Vulnerabilities? Python Edition

Injection vulnerabilities persist in Python ecosystems not because developers don’t understand SQL, but because they misunderstand where trust boundaries actually exist. We consistently observe the same systemic weakness: Applications blur the boundary between data and instructions, assuming the interpreter will figure it out. It wont. The Real Failure Mode In Python applications, injection typically emerges in two high-risk areas: 1. Raw SQL execution (even inside otherwise ORM-driven apps) 2. OS command execution via shell invocation The pattern is identical across both: - User input is embedded into a command string - The interpreter receives one unified instruction stream - Malicious tokens are executed as part of the command The issue is that Python makes string construction effortless—f-strings, concatenation, formatting—while the database engine or shell cannot distinguish where trusted code ends and untrusted input begins. Why This Persists in Mature Codebases Teams mix ORM usage with occasional raw SQL for performance or complex queries. - Developers assume framework abstractions are “safe by default.” - Shell invocation (os.system, subprocess with shell=True) is used for convenience. - Code reviews focus on logic correctness, not interpreter semantics. Injection vulnerabilities often survive because they look like normal string manipulation. Structural Controls That Actually Work 1. Use parameterized queries exclusively with no exceptions for simple cases. 2. Avoid shell=True and string-based command construction. 3. Apply least-privilege database accounts and runtime permissions. 4. Integrate SAST and DAST into CI to detect unsafe execution paths early. Parameterization is a mechanism that forces the interpreter to separate syntax from data at the protocol level. That architectural separation is the only reliable defense.