{"id":9340,"date":"2026-02-28T13:44:51","date_gmt":"2026-02-28T14:44:51","guid":{"rendered":"https:\/\/hadess.io\/?p=9340"},"modified":"2026-04-06T18:30:42","modified_gmt":"2026-04-06T18:30:42","slug":"secure-coding-python","status":"publish","type":"post","link":"https:\/\/hadess.io\/secure-coding-python\/","title":{"rendered":"Secure Python: Injection Defense, Framework Security, and Dependency Auditing"},"content":{"rendered":"

Secure Python: Injection Defense, Framework Security, and Dependency Auditing<\/h1>\n
\n

Part of the Cybersecurity Skills Guide<\/a><\/strong> \u2014 This article is one deep-dive in our complete guide series.<\/p>\n<\/blockquote>\n

By HADESS Team | February 28, 2026 | Updated: February 28, 2026 | 5 min read<\/em><\/p>\n

Python’s readability makes it popular for web applications, automation, and data pipelines. That same readability can mask security problems \u2014 dangerous functions look harmless, and the standard library includes several footguns that developers use without thinking twice.<\/p>\n

Injection Prevention<\/h2>\n

Command injection<\/strong> through os.system()<\/code> and subprocess.shell=True<\/code> is the most common Python vulnerability in security assessments. Never pass user input to a shell:<\/p>\n

“python <\/p>\n

Vulnerable<\/h1>\n

os.system(f\"ping {user_input}\")<\/p>\n

Safe<\/h1>\n

subprocess.run([\"ping\", \"-c\", \"1\", user_input], shell=False)
\n<\/code>`<\/p>\n

With <\/code>shell=False and a list of arguments, the input is passed as a single argument to the program, not interpreted by the shell.<\/p>\n

SQL injection<\/strong> follows the same pattern as other languages. Use parameterized queries:<\/p>\n

<\/code>`python<\/p>\n

Vulnerable<\/h1>\n

cursor.execute(f\"SELECT * FROM users WHERE id = {user_id}\")<\/p>\n

Safe<\/h1>\n

cursor.execute(\"SELECT * FROM users WHERE id = %s\", (user_id,))
\n<\/code>`<\/p>\n

SQLAlchemy ORM queries are parameterized by default, but <\/code>text() with string formatting is not.<\/p>\n

Template injection<\/strong> in Jinja2 allows code execution when user input is rendered as a template. Never use <\/code>Template(user_input).render(). Use <\/code>render_template() with variables passed separately.<\/p>\n

Pickle Exploits<\/h2>\n

<\/code>pickle.loads() executes arbitrary Python code during deserialization. Never unpickle data from untrusted sources. This includes data from caches, message queues, and APIs where you do not control the sender.<\/p>\n

<\/code>`python<\/p>\n

Never do this with untrusted data<\/h1>\n

import pickle
\ndata = pickle.loads(untrusted_bytes) # Arbitrary code execution
\n<\/code>`<\/p>\n

Use JSON, MessagePack, or Protocol Buffers for serialization instead. If you must use pickle, implement <\/code>__reduce__ restrictions and use <\/code>hmac to verify data integrity before deserialization \u2014 though this is still inferior to avoiding pickle entirely.<\/p>\n

Django Security<\/h2>\n

Django ships with strong defaults, but misconfigurations undo them:<\/p>\n