PHP (Stack) rules

Wrap file reads/writes (e.g., file_get_contents, file_put_contents, fopen) with checks and exceptions; never assume the filesystem is available.

Check transport errors and HTTP status codes before parsing response bodies; treat 4xx/5xx as errors with context.

Do not use the eval() function to run dynamically generated PHP code, especially if it can include user input. Look for safe alternatives like controlled function calls or explicit decision structures.

Configure your application not to display detailed error messages (stack traces, PHP warnings) to end users in production. Instead, log errors for developers and show a generic message to users.

Avoid hard‐coding credentials or sensitive information (like DB passwords, API tokens or secret keys) directly in your code. Use separate configuration files or environment variables to manage these values securely.

Avoid passing untrusted values to include/require statements. If you need to include files based on external input, strictly validate that input (for example, using a whitelist of valid filenames).

When sending session or other sensitive cookies, always enable the HttpOnly and Secure flags (and consider SameSite). HttpOnly prevents JavaScript access, and Secure ensures the cookie is only sent over HTTPS.

Always escape or sanitize user‐provided content before displaying it in HTML. Use functions like htmlspecialchars() to convert special characters into HTML entities.

Use transactions for multi-step writes; on Throwable, rollback and rethrow with context.

Use JSON_THROW_ON_ERROR (PHP ≥7.3) and wrap json_encode/json_decode in try/catch; validate the decoded shape.

Log errors with operation name and identifiers (e.g., userId, orderId) using structured context.

Replace per-row lookups with JOINs or bulk queries to fetch related data in fewer round-trips.

Implement anti‐CSRF tokens in forms performing sensitive actions (like state changes or deletions). Generate a unique token per session or request and validate it on the server before processing the form action.

Return 2xx only on success; use 4xx for client errors and 5xx for server errors, with a minimal JSON error body.

Background jobs must throw on irrecoverable failures (after logging) so the runner/queue can retry or dead-letter appropriately.

For security tokens (session IDs, CSRF tokens, password‐reset links), use cryptographically secure random functions like random_bytes() or openssl_random_pseudo_bytes(), instead of predictable functions like rand() or mt_rand().

Do not build SQL queries by directly concatenating untrusted data. Instead, use prepared statements with parameters (for example, using PDO or MySQLi) to prevent SQL Injection.

Do not use weak or generic hash algorithms (like MD5 or SHA1) for storing passwords. Use built‐in functions like password_hash() (with BCRYPT or Argon2) and password_verify(), which handle salting and secure algorithms automatically.

Wrap per-item work in try/catch, collect failures, and continue when appropriate; never let one failure abort the entire batch by default.

Never trust data received from users, forms or requests. Always validate the expected format (e.g., numbers, emails) and sanitize/remove unexpected characters or content using appropriate techniques (filter_var, filter_input, etc.).

After decoding, assert required keys and types before use; reject unexpected shapes.

Use isset()/array_key_exists() or null coalescing (??) before reading array keys that may be absent.

Every match expression must define a default arm that handles unsupported or unexpected values.

Do not perform multiple DB queries inside a loop for data you could fetch in one query. Instead, consolidate using IN clauses or JOINs to retrieve all needed data at once.