Security should not be an afterthought, but integrated from the design phase (Security by Design). This guide covers secure coding practices based on the OWASP Top 10, the global standard for the most critical security risks in web applications.
Occurs when users can access data or functions they shouldn't. The classic example is IDOR (Insecure Direct Object Reference).
// β VULNERABLE: Blindly trusting user-supplied ID
$id = $_GET['id'];
$q = $pdo->query("SELECT * FROM invoices WHERE id = $id");
// β
SECURE: Validate ownership
$id = $_GET['id'];
$user_id = $_SESSION['user_id'];
$stmt = $pdo->prepare("SELECT * FROM invoices WHERE id = ? AND owner_id = ?");
$stmt->execute([$id, $user_id]);
Insecure storage of sensitive data. Never use obsolete algorithms like MD5 or SHA1 for passwords.
// β VULNERABLE: Fast hashing without Salt
$hash = md5($_POST['password']);
// β
SECURE: Modern algorithms with automatic Salt (Bcrypt)
$hash = password_hash($_POST['password'], PASSWORD_DEFAULT);
To prevent SQL Injection, the only 100% effective defense is Prepared Statements.
// β VULNERABLE: Direct concatenation
$pdo->query("SELECT * FROM users WHERE email = '" . $_POST['email'] . "'");
// β
SECURE: Prepared statements
$stmt = $pdo->prepare("SELECT * FROM users WHERE email = :email");
$stmt->execute(['email' => $_POST['email']]);
As a DevSecOps Engineer, you've been assigned to review legacy code. Identify insecure native PHP functions and apply industry-recommended patches to secure the build pipeline.
>_ START CTF 09 CHALLENGEDefault credentials, unnecessary services, or verbose error stack traces exposed in production.
# β VULNERABLE (php.ini)
display_errors = On
# β
SECURE
display_errors = Off
log_errors = On