PHP Security

MD5 and SHA-1 are built to be fast, so an attacker tries billions of guesses a second — a salt only defeats precomputed rainbow tables, it does not slow brute force down. password_hash() uses bcrypt or argon2: a random per-hash salt plus a tunable cost factor make every guess deliberately expensive. password_verify() reads the algorithm, salt and cost back out of the stored string.

Injection happens when user input is concatenated into the SQL string, so it becomes syntax the parser executes. A prepared statement sends the query to the server first — it is parsed and planned before any value arrives — and the bound parameters travel separately, as data. A parameter therefore can never turn into SQL.

CSRF works because the browser attaches your session cookie to any request to your origin, including a form posted from an attacker's page — so the cookie proves nothing about where the request came from. A token the server embedded in your page cannot be read cross-site, so only your page can submit it. SameSite narrows the attack but is defence-in-depth, not a replacement.

A committed secret lives in the repository history forever — every clone, fork and CI log has it, and deleting the line in a later commit does not take it back out. Keep secrets in environment variables or a secret manager, commit only a .env.example with empty values, and gitignore the real .env. A leaked key has to be rotated, not merely removed.

The cookie holds only the session id — an opaque random string. The data in $_SESSION lives server-side, by default in a file under session.save_path, keyed by that id. The id is therefore a bearer token: whoever holds it is that user, which is why it must be unpredictable, sent over HTTPS, and marked HttpOnly.

XSS is attacker-controlled data rendered as markup or script in another user's browser. htmlspecialchars() encodes <, >, & and quotes, which makes a value safe as text in the HTML body and, with ENT_QUOTES, inside a quoted attribute. It does not make it safe inside a <script> block, a javascript: URL or an unquoted attribute — escaping is per context.

Validation decides whether data is acceptable for your domain — an email looks like an email, an age is 0-150 — and it runs once, on the way in. Encoding decides how a value renders safely in one specific context, and it runs on every output. Only encoding stops XSS: the same stored string is safe as HTML text and dangerous inside a <script> block. Validation narrows the input; it does not make it printable.

It counts requests per identity per time window. The counter is keyed by whatever identifies the caller — an API key, a user id, or the IP address when there is nothing better — combined with the window. It lives in shared storage such as Redis, not in PHP memory, because every PHP-FPM worker serves a different request. Over the limit you answer 429 with Retry-After.

The attacker plants a session id they already know — through a link, a subdomain or an injected cookie — and waits for the victim to log in under it. That id is now authenticated, and the attacker holds it. The fix is to issue a fresh id the moment privilege changes: session_regenerate_id(true) right after password_verify() succeeds, which also destroys the old session data.

A placeholder is a value slot: the server parses the query first, so a bound parameter can only ever be data — never an identifier or a keyword. ORDER BY :col would sort by a constant string, not by the column. Map the input through an allowlist — an array of permitted column names — and interpolate only the value you looked up. The ASC/DESC direction goes through an allowlist too.

Put the counter in shared storage — Redis with an atomic INCR and an expiry — as each worker is its own process. Key it by identity, not by connection: the account id once authenticated, the API key for partners, the address only as the anonymous fallback, so one NAT'd office is not a single bucket. Limit login separately, far tighter. A sliding window stops a burst doubling across a fixed boundary. Answer 429 with Retry-After, and pick the store's failure mode: fail-open or fail-closed.

Values bind: the filters, the IN list (one generated placeholder per element) and the LIMIT. Identifiers do not — the sort column and its direction must come from an allowlist, never from the request. PDO::quote() is not a substitute for binding. And ATTR_EMULATE_PREPARES = true means PDO interpolates client-side, so there is no server-side parse-then-bind at all; turn it off. Finally make them show an EXPLAIN and a measurement — the ORM was slow is a claim, not a finding.