Author: Kateryna Ivanenko, Invicti & Mend.io Brand Manager
Python is widely used for web applications nowadays, but it is not safe from security issues. This article lists widespread vulnerabilities in this programming language and their main prevention methods, so you can take control over your application protection.
Injection vulnerabilities
An injection vulnerability is a critical security flaw where an application mistakenly processes untrusted user data as if it were valid commands or code.
Examples: SQL injection, code injection, command injection, cross-site scripting (XSS).
It is listed in the current edition of OWASP Top 10 (2025) as a major risk.
A strong way to prevent such vulnerabilities is to ensure that data remains separate from commands and queries.
The recommended approach is to use a secure API that either avoids direct interaction with an interpreter, supports parameterized queries, or relies on Object Relational Mapping (ORM) tools.
However, parameterization alone does not fully eliminate risk. Stored procedures may still lead to SQL injection if PL/SQL or T-SQL concatenates queries and data or executes dangerous data with EXECUTE IMMEDIATE or exec().
When complete separation between data and commands is not feasible, the risk can be reduced through additional controls:
- Applying a strict server-side allowlist for input validation. This should not be treated as a complete safeguard, since many applications must accept special characters.
- Escaping special characters using the specific escape syntax for that interpreter, in case of residual dynamic queries. SQL structures such as table names cannot be escaped, therefore, names provided by users are potentially dangerous.
Insecure deserialization
It is a vulnerability that occurs when an application takes untrusted data and reconstructs (deserializes) it into an object without proper validation. This flaw lies in A08:2025 — Software or Data Integrity Failures of the OWASP Top 10.
Python’s pickle is a classic example of a dangerous deserialization mechanism when used with untrusted data.
It can lead to code execution, object manipulation, injection, or access control bypass.
The safest approach is to avoid accepting serialized objects from untrusted sources, or to use serialization mediums that only permit primitive data types.
Where this is not possible, the following controls are recommended by OWASP:
- Applying integrity checks (such as digital signatures) on serialized objects.
- Enforcing strict type constraints during deserialization before objects are created.
- Isolating and running code that deserializes in low privilege environments when possible.
- Logging deserialization errors and exceptions.
- Restricting or monitoring incoming and outgoing network connectivity from containers or servers that deserialize.
- Monitoring deserialization, alerting if a user deserializes constantly.
Directory Traversal
Directory traversal (also known as path traversal) is a vulnerability that lets attackers access and read files from restricted areas of the server.
It falls under the most dangerous category in OWASP Top 10 — Broken Access Control.
Their prevention advice lists the following measures:
- Avoiding relying on user-supplied input when using file system calls.
- Applying indexes instead of actual portions of file names when templating or using language files.
- Building the path in application code and only inserting strictly controlled values from users where necessary.
- Validating user input with allowlists.
- Using chrooted jails (a process isolation mechanism in Unix/Linux systems, when the root directory for a program is artificially changed) and code access policies to restrict where the files can be obtained or saved to.
- Normalizing user input if it must be used in file operations.
Vulnerable and outdated dependencies
Python applications commonly depend on many third-party packages. A single vulnerable dependency can expose the whole app, especially when libraries handle authentication, cryptography, or file processing.
The following steps are recommended for risk reduction:
- Maintaining an inventory of libraries (SBOM, Software Bill of Materials)
- Reducing attack surface by removing unused dependencies
- Using trusted sources when searching for new packages
How to detect these vulnerabilities
Ultimately, the only way to know for sure whether your applications has the vulnerabilities mentioned above is security testing.
The following automated tools are commonly used for this purpose:
- SAST — finding vulnerabilities in source code.
- DAST — safely imitating attacker’s actions during runtime.
- SCA — checking security of libraries.
The best option is to use all of them, since SAST can uncover issues in earlier stages of development, DAST can validate them and find more complex vulnerabilties, and SCA provides component coverage.
If you want to test such tools for free, please leave your contact details below and we will reach out to you:
