Secure
Software
Development
in Python.

eval() takes a string and runs it as Python. That includes anything a user might type — including __import__('os').system('rm -rf /'). If the input isn't fully trusted, eval is unsafe by default.

Vulnerable

user_input = input("Enter a mathematical expression (e.g., 2+2): ")
print(eval(user_input))
# Try entering: __import__('os').system('dir')

Secure alternative

import ast
import operator

def safe_eval(expr):
    allowed_ops = {
        ast.Add: operator.add,
        ast.Sub: operator.sub,
        ast.Mult: operator.mul,
        ast.Div: operator.truediv
    }

    def eval_node(node):
        if isinstance(node, ast.BinOp):
            return allowed_ops[type(node.op)](
                eval_node(node.left),
                eval_node(node.right)
            )
        elif isinstance(node, ast.Num):
            return node.n
        else:
            raise ValueError("Unsupported operation")

    tree = ast.parse(expr, mode='eval')
    return eval_node(tree.body)

expr = input("Enter a simple math expression (e.g., 2+3*4): ")
print("Result:", safe_eval(expr))

A user enters file.txt; rm -rf / and os.system() happily runs both halves. Subprocess with a list argument bypasses the shell entirely — arguments are passed straight to the kernel, no parsing, no chaining.

Vulnerable

import os

filename = input("Enter filename to delete: ")
os.system(f"rm {filename}")
# A user types: file.txt; rm -rf /

Secure alternative

import subprocess
from pathlib import Path

filename = input("Enter filename to delete: ")

if Path(filename).exists():
    subprocess.run(["rm", filename])
else:
    print("File does not exist.")

The moment a secret enters your repo, it's effectively public. GitHub bots actively scan public commits for leaked credentials — and even private repos get cloned, shared, baked into Docker images, and posted in support tickets. Push secrets out of code into a .env file ignored by git.

Vulnerable

API_KEY = "abc123XYZ"
print("Using API Key:", API_KEY)

Secure alternative

from decouple import config

API_KEY = config('API_KEY')
print("Using API Key:", API_KEY)

API_KEY=abc123XYZ

A vulnerable version of requests can leak headers. An outdated flask can let an attacker write arbitrary files. Three free tools catch the vast majority of these issues before deployment.

Run all three

# Install
pip install bandit safety pip-audit

# Run them
bandit -r .
safety check
pip-audit

Python's random module is deterministic — given the same seed, it produces the same sequence. That makes it useless for anything an attacker might want to guess: session tokens, password reset links, API keys, OTPs. The secrets module uses the operating system's cryptographic source.

Vulnerable

import random
token = str(random.random())
print("Token:", token)

Secure alternative

import secrets

token = secrets.token_urlsafe(16)
print("Secure token:", token)

AWS keys in debug logs. Authorization headers in error reports. Reset tokens in stdout that gets piped to a public S3 bucket. Every one of these has happened, repeatedly, at companies you've heard of. The fix is simple: log events, never secrets.

Vulnerable

username = input("Username: ")
password = input("Password: ")
print(f"User tried to login with {username}:{password}")

Secure alternative

import logging

logging.basicConfig(level=logging.INFO)

username = input("Username: ")
password = input("Password: ")  # Used but not logged

logging.info(f"Login attempt by user: {username}")
# Never log passwords!

Type confusion is a security issue, not just a bug. Unvalidated strings flowing into SQL, file paths, or JSON parsers is how injection happens. Convert and validate at the boundary — every time.

Vulnerable

age = input("Enter your age: ")
print("Next year you will be:", age + 1)
# TypeError: can only concatenate str (not "int") to str

Secure alternative

try:
    age = int(input("Enter your age: "))
    print("Next year you will be:", age + 1)
except ValueError:
    print("Invalid age input")

Bonus: email validation

import re

email = input("Enter your email: ")
pattern = r'^[\w\.-]+@[\w\.-]+\.\w+$'

if re.match(pattern, email):
    print("Valid email")
else:
    print("Invalid email format")

Hashing is one-way. Even with a database leak, attackers can't reverse a bcrypt hash back into a password — and because bcrypt is intentionally slow and salted, brute-force and rainbow tables stop working. MD5 and SHA-1 are not options here. They were designed for speed; password hashing wants the opposite.

Vulnerable

users = {"admin": "password123"}
# A database leak immediately exposes every credential.

Secure alternative

import bcrypt

# Hash the password
password = input("Enter your password: ").encode()
hashed = bcrypt.hashpw(password, bcrypt.gensalt())
print("Stored hash:", hashed)

# Verification (for demo)
if bcrypt.checkpw(password, hashed):
    print("Password match!")
else:
    print("Incorrect password")

A user enters ' OR 1=1 -- and the query becomes SELECT * FROM users WHERE username = '' OR 1=1 --'. Authentication bypassed. Data dumped. Tables dropped. Parameterized queries solve this completely — input is treated as data, never as code.

Vulnerable

import sqlite3

conn = sqlite3.connect("users.db")
cur = conn.cursor()

username = input("Username: ")
query = f"SELECT * FROM users WHERE username = '{username}'"
cur.execute(query)
# An attacker types: ' OR 1=1 --

Secure alternative

import sqlite3

conn = sqlite3.connect("users.db")
cur = conn.cursor()

username = input("Username: ")
cur.execute(
    "SELECT * FROM users WHERE username = ?",
    (username,)
)

user = cur.fetchone()
if user:
    print("User found:", user)
else:
    print("No user found")