227 Php Developer Interview Questions & Answers

SQL injection is when untrusted input changes the structure or meaning of a database command. Prevent it with parameterized prepared statements for values, allow-listing for dynamic identifiers, least-privilege database permissions, safe error handling, and verification. Manual escaping alone is not a complete defense.

SQL injection happens when information supplied by a person is allowed to change what a database request means. Instead of treating that information only as a value, the application accidentally lets it become part of the instruction. An attacker may then make the application read information they should not see, change or remove stored information, or sometimes get past a sign-in check. The safe design keeps the fixed instruction separate from supplied values, limits what the application is allowed to do, and avoids showing private details when something goes wrong.

1. Are you asking mainly about SQL injection through data values, or should I also cover dynamic table names, column names, and sort directions?
2. Should I show the prevention approach using PHP PDO prepared statements?

SQL injection is a vulnerability where untrusted input changes the structure or meaning of an SQL command. The important security boundary is between SQL code, which the application controls, and data, which may come from an untrusted user.

A vulnerable application might build SQL by concatenating a submitted value directly into a query string. That mixes SQL code and untrusted data. Special characters or SQL syntax in the supplied value may then change the intended command instead of being treated only as data.

The impact depends on the vulnerable query and the permissions of the application's database account. SQL injection may allow unauthorized reading of data, modification of records, deletion of data, or other database operations that the account is permitted to perform. In a vulnerable sign-in query, changed SQL logic may also cause the authentication condition to evaluate differently and potentially bypass the intended login check.

Authentication answers, "Who are you?" Authorization answers, "What are you allowed to do?" SQL injection is different from both, but a successful injection can undermine application logic used for authentication or authorization when that logic depends on a vulnerable database query.

The primary defense for data values is parameterized prepared statements. The application writes the SQL structure separately and sends untrusted values as parameters. The database driver and database handle those values as data rather than letting their contents become SQL syntax. In PHP, PDO prepared statements are a common way to apply this control.

Prepared-statement parameters are for data values, not arbitrary SQL identifiers such as table names, column names, or sort directions. If an identifier must be dynamic, map the requested choice to a small application-controlled allow-list. For example, a request for "name" can map to the fixed identifier "display_name". Never copy an arbitrary user-supplied identifier directly into SQL.

Input validation is still useful for enforcing business rules. An application can verify that an ID has the expected form or that a requested sort option is supported. However, validation or filtering does not replace parameterized queries. A value can be valid for the business rule and still be dangerous if it is concatenated into SQL.

Least privilege reduces the damage if another control fails. The database account used by the PHP application should have only the permissions that the application actually needs. A read-only operation should not use an account that can modify or delete unrelated data or perform database-administration tasks.

Errors should fail safely. Users should receive a generic error message rather than SQL text, database details, credentials, or stack traces. Server-side logs should contain enough information for investigation, such as an internal request identifier or error category, but should not contain passwords, database credentials, session secrets, or unnecessary sensitive data.

Manual escaping alone is not a complete defense. Correct escaping depends on the database driver, connection configuration, character handling, and the exact SQL context. It is also easy for a developer to forget to escape one value or to apply the wrong rule. Parameterized prepared statements provide a clearer and more reliable code-and-data boundary for values.

Other security controls solve different problems. Output encoding helps prevent injection into HTML or other output contexts. CSRF protection helps stop unwanted state-changing requests made with a victim's authenticated session. Secure session handling protects session state. File-upload controls protect uploaded content, and dependency management reduces third-party software risk. These controls are important when relevant, but none replaces SQL injection prevention.

To verify the defense, review database calls for string concatenation involving untrusted data. Confirm that data values use parameters and that dynamic identifiers come only from fixed allow-lists. Test with ordinary values and malicious-looking strings containing quotes, operators, comments, or SQL keywords. Those strings must remain ordinary data and must not change the SQL command. Also verify that database errors shown to users do not reveal sensitive implementation details and that the database account has only the required privileges.

1. Identify every database input that can be influenced by an untrusted source.
2. Keep the SQL statement structure fixed.
3. Send data values through parameterized prepared statements.
4. If a table name, column name, or sort direction must be dynamic, map it through an application-controlled allow-list.
5. Validate input for business rules without treating validation as the SQL injection defense.
6. Run the application with only the database permissions it requires.
7. Return generic errors to users and log useful diagnostic information without secrets.
8. Review and test the database calls to confirm hostile-looking input remains data and cannot alter the SQL command.

Common mistakes include concatenating request values into SQL, assuming validation or filtering alone prevents SQL injection, relying on manual escaping instead of parameterized statements, trying to bind table or column names as data parameters, inserting user-controlled identifiers directly into SQL, using a database account with unnecessary privileges, exposing SQL text or stack traces in production error responses, logging credentials or other sensitive values, and testing only normal inputs instead of verifying that hostile-looking inputs remain data.

Start with the central rule: keep SQL code and untrusted data separate. Then explain parameterized prepared statements for values, allow-listing for dynamic identifiers, least privilege, safe error handling, and verification. Finish by saying that input filtering and manual escaping alone are not complete defenses.

XSS happens when untrusted content is interpreted as executable browser code in another user's session. Prevent it mainly with context-aware output encoding and safe rendering. Sanitize intentionally permitted HTML, use safe templates and DOM APIs, and use Content Security Policy as defense in depth.

Cross-site scripting is a security problem where information controlled by one person is shown to another visitor in a way that the browser treats as instructions instead of normal content. This can let the attacker change what the visitor sees, perform actions using the visitor's signed-in session, read information that the page is allowed to access, or send accessible information elsewhere. The safest design is to keep untrusted values as plain data when displaying them. If a feature intentionally allows formatted content, it needs stricter handling and additional browser protections.

1. Are users allowed to submit any HTML, or should all user-controlled content be displayed only as text?
2. Should I cover both server-rendered PHP output and browser-side JavaScript handling?

XSS means untrusted content reaches a browser and is interpreted as executable browser code instead of harmless data. The important security decision is to make the data safe for the exact context where it is inserted into the page.

There are three common forms of XSS. Reflected XSS happens when attacker-controlled input, such as a query parameter, is immediately included in a server response without the correct protection. A victim may execute the attack by opening a crafted URL or submitting a crafted request. Stored XSS happens when attacker-controlled content is saved, for example in a comment, profile field, or message, and is later rendered to other users. DOM-based XSS happens when browser-side JavaScript reads untrusted data and passes it to an unsafe DOM operation, allowing the browser to create executable content even when the server response itself did not directly contain the final dangerous markup.

The impact depends on the execution context and the privileges of the victim's page and session. XSS can change page content, read data available to JavaScript, capture information typed into the page, send accessible information to another server, or make requests using the victim's authenticated session. An HttpOnly session cookie cannot be read directly by JavaScript, which reduces cookie theft, but XSS can still perform same-origin actions from the victim's page if the application accepts those actions.

The primary defense is contextual output encoding. Contextual means that the escaping method must match where the untrusted value is inserted. HTML text, HTML attributes, URLs, JavaScript, and CSS are different contexts and do not all have the same escaping rules. For ordinary HTML text or a properly quoted HTML attribute in PHP, htmlspecialchars() with ENT_QUOTES | ENT_SUBSTITUTE and UTF-8 is a common safe baseline. Developers should still avoid placing untrusted data directly into executable JavaScript or CSS contexts when a safer design is available.

Safe templating systems reduce risk because they normally escape variables automatically for the context they support. Automatic escaping should remain enabled. Raw-output features should be avoided unless the value has been deliberately made safe for that exact context.

Browser-side code should also use APIs that treat untrusted values as data. For example, assigning plain text with textContent is safer than placing untrusted content into innerHTML. If HTML markup is not required, do not parse user-controlled input as HTML.

If an application intentionally permits users to submit a limited subset of HTML, normal output encoding would display the markup as text instead of rendering it. In that case, use a well-maintained HTML sanitizer configured with an allowlist of permitted elements, attributes, and URL schemes. Sanitization must understand HTML structure; simple string replacement, regular-expression filtering, or a blacklist is not a complete XSS defense.

Content Security Policy, or CSP, is an HTTP response policy that limits which scripts and other resources the browser may execute or load. A strong CSP can reduce the impact of some XSS mistakes, especially when arbitrary inline script execution is restricted and trusted scripts use nonces or hashes. CSP is defense in depth. It does not replace correct output encoding, safe templating, safe DOM APIs, or sanitization.

Input validation is useful for enforcing business rules. For example, an application can require a numeric identifier to contain only the expected numeric format or limit the length of a display name. However, input validation alone cannot prevent XSS because a value may be valid for the application and still become dangerous when inserted into the wrong browser context. The application must therefore protect the data at the point where it is rendered or interpreted.

For safe failure behavior, reject malformed input when the application's business rules require rejection, but do not expose internal implementation details, stack traces, tokens, session identifiers, or secrets. Security logging can record useful information such as the affected endpoint, the type of validation failure, or a CSP violation, but logs should avoid passwords, authentication tokens, raw session identifiers, and unnecessary sensitive data.

To verify the controls, test each location that renders untrusted data with representative hostile values and confirm that the browser treats them as data rather than executable code. Test server-rendered templates and browser-side DOM insertion points separately. Automated tests can verify expected escaping or sanitization behavior, and browser testing can confirm that no script executes. CSP violation reporting can provide additional production evidence, but it should supplement rather than replace direct security testing.

1. Find every place where untrusted data reaches an HTML response or browser-side DOM operation.
2. Identify the exact context: HTML text, HTML attribute, URL, JavaScript, CSS, or intentionally permitted HTML.
3. Prefer safe templates and browser APIs that treat values as data.
4. Apply context-appropriate output encoding when rendering ordinary untrusted content.
5. If limited HTML is intentionally permitted, sanitize it with a maintained allowlist-based HTML sanitizer.
6. Add a restrictive Content Security Policy as defense in depth.
7. Keep input validation for business rules, but do not rely on it as the primary XSS control.
8. Test hostile inputs in every rendering context and verify that the browser does not execute them.

Output encoding normally processes each character in the value, so its time cost grows roughly with the amount of text being rendered. It also creates an encoded output string, so memory use grows with that output. HTML sanitization is more expensive because the sanitizer must parse and inspect the permitted markup. CSP adds little request-processing cost but creates configuration and maintenance work. The largest long-term cost is ensuring that every new template and browser-side rendering path continues to use the correct protection for its context.

Common mistakes include relying only on input validation or blacklist filtering, escaping data when it enters the database instead of when it is rendered, assuming one escaping function works for every browser context, disabling template auto-escaping, placing untrusted strings into innerHTML, allowing raw HTML without a robust sanitizer, assuming HttpOnly cookies remove all XSS impact, and treating Content Security Policy as a replacement for fixing the unsafe rendering path.

Start with the core rule: XSS occurs when untrusted data becomes executable browser code in another user's session. Then distinguish reflected, stored, and DOM-based XSS. Explain context-aware output encoding as the primary defense, safe templates and DOM APIs, sanitization for intentionally permitted HTML, and CSP as defense in depth. Explicitly state that input validation alone is insufficient.

CSRF tricks a signed-in user's browser into sending an unwanted state-changing request to a trusted site. Because the browser may automatically include session cookies, the site may accept it. Prevent it with CSRF tokens, SameSite cookies, origin checks, safe HTTP methods, and stronger confirmation for sensitive actions.

A harmful website can sometimes make your browser perform an action on another website where you are already signed in. Your browser may automatically carry proof that you are signed in, so the second website may believe you chose the action yourself. For example, an attacker might try to make your browser change an account setting without your intention. The protection must make sure important actions really came from the website page the user was using. Several protections should work together because no single browser or network feature solves every case.

1. Should I explain CSRF protection for a traditional PHP application that uses session cookies?
2. Should I cover both browser-level protections and server-side verification?
3. Do you want an example of handling highly sensitive actions such as changing an email address or password?

CSRF, or cross-site request forgery, happens when an attacker causes a user's browser to send an unwanted request to a site where that user is already authenticated. Authentication proves who the user is, but it does not prove that the user intentionally initiated that particular action. Authorization separately decides whether the authenticated user is allowed to perform the action. CSRF protection is needed because a request can be both authenticated and authorized while still not representing the user's intent.

A typical CSRF attack needs three important conditions. First, the application uses credentials that the browser sends automatically, commonly a session cookie. Second, the targeted endpoint changes server state, such as changing an email address, updating settings, or making a purchase. Third, the server accepts the request without requiring evidence that an attacker on another origin normally cannot provide.

For a traditional PHP application using cookie-based sessions, the main server-side defense is usually a CSRF token. The application generates a cryptographically unpredictable value and associates it with the user's session. Legitimate forms or application requests include that token. Before processing a protected state-changing request, the server checks that the submitted token matches the expected token. If it is missing or invalid, the application must reject the request before changing any data. In a custom PHP implementation, a token can be generated with random_bytes() and compared with hash_equals(). Frameworks commonly provide their own tested CSRF protection and should normally be used instead of rebuilding it.

The token works because an attacker can often cause the browser to send a request but normally cannot read pages or token values from another origin because of the browser's same-origin policy. If the application also has a cross-site scripting vulnerability, however, injected script running in the application's own origin may be able to read or submit CSRF tokens. CSRF protection therefore does not replace protection against cross-site scripting.

SameSite cookies provide another layer of protection. SameSite=Lax prevents cookies from being sent on many cross-site requests while still allowing some top-level navigations. SameSite=Strict is more restrictive and generally prevents the cookie from being sent during cross-site navigation, but it can interfere with legitimate flows from external sites. SameSite=None permits cross-site cookie use and requires the Secure attribute. SameSite is useful defense in depth, but the correct setting depends on the application's legitimate cross-site requirements and should not automatically replace server-side CSRF validation for important cookie-authenticated actions.

Origin checking is another useful layer. For state-changing requests, the server can verify that the Origin header matches an explicitly trusted origin. When Origin is unavailable, carefully validating Referer can be an appropriate fallback. The comparison should use an exact trusted scheme, host, and port policy rather than unsafe substring matching. Deployment details such as reverse proxies and canonical hostnames must also be handled correctly.

HTTP methods must have correct semantics. GET and HEAD are defined as safe methods and should not perform state-changing operations. Operations that create, update, or delete data should use an appropriate state-changing method such as POST, PUT, PATCH, or DELETE. However, simply changing an endpoint from GET to POST does not prevent CSRF. An attacker can often make a browser submit a cross-site POST form, and the browser may still attach applicable cookies automatically.

HTTPS also does not prevent CSRF. HTTPS protects the connection against network eavesdropping and modification, but CSRF uses the victim's own browser to create the request. The forged request can therefore be fully encrypted with HTTPS and still be unwanted.

For especially sensitive operations, such as changing a password, changing account recovery information, or confirming a financial action, the application can require re-authentication or another strong explicit confirmation in addition to normal CSRF defenses. This reduces the chance that possession of an existing authenticated session is enough to complete a high-impact action.

Protection should fail safely. If CSRF validation fails, return an appropriate error such as HTTP 403 and perform no state change. Log enough information to investigate repeated failures, such as the endpoint, time, and a request correlation identifier, but do not log passwords, session identifiers, CSRF tokens, or other secrets.

To verify the control, test a legitimate state-changing request with a valid token and confirm that it succeeds. Then send requests with a missing token, an incorrect token, and an unexpected Origin and confirm that every invalid request is rejected before any data changes. Also verify that GET and HEAD endpoints do not change application state and review the session cookie's SameSite, Secure, and HttpOnly settings.

1. Identify every endpoint that changes server state.
2. Ensure safe methods such as GET and HEAD do not change state.
3. For cookie-authenticated browser requests, generate or use the framework's cryptographically unpredictable CSRF token associated with the user's session.
4. Include that token in legitimate state-changing forms or requests.
5. Validate the token before performing the action.
6. Configure session cookies with an appropriate SameSite policy and use Secure and HttpOnly where applicable.
7. Validate Origin, with a carefully implemented Referer fallback where appropriate, as defense in depth.
8. Require re-authentication or stronger confirmation for highly sensitive operations.
9. Reject failures before any state change and log diagnostic information without secrets.
10. Test valid, missing-token, invalid-token, and unexpected-origin cases.

CSRF protection adds very little processing or memory cost. Creating or comparing a small token and checking request headers take constant work per request and use only a small amount of data. The larger cost is operational and maintenance work: every state-changing endpoint must consistently use the protection, cookie settings must match legitimate browser flows, and automated tests should prevent future endpoints from accidentally bypassing the controls.

Common mistakes are believing that authentication alone prevents CSRF, treating authorization as proof of user intent, using POST without CSRF validation, assuming HTTPS blocks forged requests, allowing GET requests to change data, using predictable tokens, accepting missing or invalid tokens, comparing origins with unsafe substring checks, treating SameSite as the only defense without considering application requirements, disabling protection for convenient endpoints, logging session identifiers or CSRF tokens, and changing application state before validation finishes.

Define the attack first, then explain the conditions that make it possible. Say clearly that authentication identifies the user but does not prove intent. Present CSRF tokens as the main application defense for traditional cookie-based sessions, then add SameSite cookies, origin checks, safe HTTP methods, and re-authentication as layered protections. Explicitly state that HTTPS and POST alone do not prevent CSRF.

Authentication answers, "Who are you?" Authorization answers, "What are you allowed to do?" Login may create a session or token that represents the authenticated identity, but every protected request must still check whether that identity may perform the requested action on the requested resource.

A secure application makes two separate decisions. First, it checks that a person or connected service really is who it claims to be. Second, it decides what that person or service is allowed to see or change. Passing the first check does not give unlimited access. A signed-in customer should not automatically see another customer's information, and a normal employee should not automatically perform administrator actions. The application should give only the access that is needed and refuse access when permission has not been clearly granted.

1. Should I explain this mainly for a normal PHP web application with user sessions, or also include API tokens?
2. Do you want examples of role-based permissions and checks for access to individual records?

Authentication proves identity. For example, a PHP application may verify login credentials and then create a secure server-side session. An API may instead validate a token that represents an authenticated user or service. A session or token helps the application recognize the same authenticated identity on later requests, but it does not by itself grant permission to every resource or action.

Authorization happens after the identity is known. It decides whether that identity may perform a specific action on a specific resource. For example, a user may be authenticated but still be forbidden from deleting users, opening an administrator page, or reading another customer's order.

Roles and permissions can provide broad authorization rules. A role such as admin may have permissions that a normal user role does not have. However, role checks alone are often not enough. The application may also need an object-level check. For example, before returning order 123, the server should verify that the current user is allowed to read that specific order, not merely that the user is logged in.

Authorization should follow least privilege. Each identity should receive only the permissions it needs. It should also follow deny by default. If no authorization rule clearly allows an action, the request should be rejected.

The server must enforce authorization on every protected request. A previous successful login does not replace the authorization check. The application must not rely on hidden buttons, disabled controls, URLs that are difficult to guess, or checks performed only in browser code because a requester can send HTTP requests directly to the server.

Failure should be safe. If authentication is missing or invalid, reject access without exposing sensitive information. If authentication succeeds but authorization fails, refuse the protected action. Log useful security information such as the identity identifier, attempted action, requested resource identifier, result, and request correlation information when appropriate. Do not log passwords, session identifiers, access tokens, or other secrets.

To verify the controls, test both allowed and denied cases. Confirm that an unauthenticated requester cannot reach protected functionality, a lower-privileged authenticated user cannot perform a higher-privileged action, and one authenticated user cannot access another user's protected object merely by changing an identifier. Also verify that missing or unknown permission rules result in denial rather than accidental access.

1. Authenticate the requester and establish a trusted identity using a secure session or validated token.
2. Identify the requested action and resource.
3. Determine the permissions or policy that apply to that identity.
4. Check broad authorization rules such as roles or explicit permissions.
5. Perform an object-level authorization check when access depends on ownership, membership, tenancy, or another relationship to the resource.
6. Deny the request when no rule explicitly allows it.
7. Execute the protected action only after authorization succeeds.
8. Fail safely and log useful security events without secrets.
9. Test successful access, missing authentication, insufficient permission, and access to another user's protected object.

Authentication and authorization add some work to every protected request. Session authentication may require reading session data, while token authentication requires validating the token. Authorization may require checking permissions and sometimes reading ownership, membership, or other resource information from storage. Memory use is usually small. The larger cost is maintenance: roles, permissions, and object-level rules must stay correct as the application changes. Centralized and reusable authorization policies make these rules easier to test and maintain.

Common mistakes include treating successful login as permission to access everything, checking only a user's role without checking the requested object, trusting authorization decisions made only in browser code, protecting a page while forgetting the underlying API endpoint, allowing access when no permission rule exists, checking authorization only once instead of on every protected request, and logging passwords, session identifiers, access tokens, or other secrets.

Start with the simple distinction: authentication proves identity; authorization decides permitted actions and resources. Then give one example of a logged-in user being denied access to another user's record. Mention least privilege, deny by default, server-side checks on every protected request, and object-level authorization.

Use password_hash() to create an adaptive one-way hash and password_verify() to check it. Prefer PASSWORD_ARGON2ID when available, otherwise use PASSWORD_DEFAULT. PHP handles the salt. After successful verification, use password_needs_rehash() to upgrade hashes created with an older algorithm or cost.

Passwords should be saved so nobody can turn the saved value back into the original words. When a person signs in, the application should check the entered password against the saved protected value. The checking process should be deliberately slow enough to make large numbers of guesses costly, while remaining acceptable for normal users. The saved value should include everything needed for later checking and should be replaceable with stronger protection over time. Failed sign-ins should not reveal whether an account exists, and passwords must never appear in logs.

Useful clarifying questions:

• Is Argon2id available in the PHP build used in production?
• Does the application already contain hashes created by an older method?
• What login response-time and memory limits must the application meet?

Use PHP's built-in password hashing API instead of designing a custom format. Create a password hash with password_hash() and verify it with password_verify(). A password hash is a one-way derived value. It should be practical to calculate once during registration or login but expensive for an attacker to calculate repeatedly for many guesses.

Use PASSWORD_ARGON2ID when the PHP build supports Argon2id. Argon2id is an adaptive, memory-hard password-hashing algorithm. Adaptive means its cost can be increased as hardware becomes faster. Memory-hard means each guess requires a configured amount of memory as well as processor time, which makes large-scale offline cracking more expensive.

Argon2id availability depends on how PHP was built. The application can check whether PASSWORD_ARGON2ID is defined or whether 'argon2id' appears in password_algos(). If Argon2id is unavailable, use PASSWORD_DEFAULT. In PHP 8.4 and PHP 8.5, PASSWORD_DEFAULT remains an alias for bcrypt, but the alias may change in a future major PHP release.

Do not manually generate or store a separate salt. PHP creates a cryptographically secure random salt for every call to password_hash(). The returned string contains the algorithm identifier, salt, cost parameters, and derived value. Store that complete string without changing or truncating it. Because PASSWORD_DEFAULT may produce a different-length format in the future, a VARCHAR(255) or equivalent binary-safe text column is a practical storage choice.

At login, retrieve the stored hash and call password_verify($submittedPassword, $storedHash). Do not call password_hash() again and compare the two strings because a new random salt normally produces a different hash each time. Do not write a custom equality or timing-safe comparison routine; password_verify() reads the algorithm and parameters from the stored hash and performs verification in a timing-attack-safe way.

After password_verify() succeeds, call password_needs_rehash() with the application's current algorithm and options. It returns true when the stored hash does not use those settings. If rehashing is needed, call password_hash() using the password that was just successfully verified and update the stored value. The update should be performed safely, preferably with a conditional database update or transaction so concurrent successful logins do not overwrite a newer hash incorrectly.

Never store plaintext passwords. Do not use reversible encryption because anyone who obtains the decryption key could recover every password. Do not use MD5, SHA-1, or a single SHA-256 or SHA-512 operation. These general-purpose hashes are intentionally fast, so an attacker with a stolen database can test very large numbers of guesses. Adding a salt to a fast hash prevents simple precomputed-table reuse but does not provide the deliberate cost of an adaptive password-hashing algorithm.

Authentication and authorization are different. Password verification authenticates the user's identity. Authorization is the later decision about which records, pages, or actions that authenticated user may access. A correct password check must not automatically grant unrestricted access.

Use the same general response for an unknown account and a wrong password, such as "Invalid credentials." This reduces direct account-enumeration information. Keep the public response generic, but record suitable internal security events such as repeated failures, operational errors, and request identifiers. Never log the plaintext password, reset token, full stored hash, or other authentication secrets.

Password hashing mainly protects against offline attacks after stored hashes are stolen. It does not by itself stop online guessing. Apply rate limiting, temporary backoff, monitoring, and appropriate multi-factor authentication separately where the application's risk requires them.

Benchmark the chosen algorithm and options on production-like hardware. Higher Argon2id memory or time settings increase resistance to cracking, but they also increase login latency, memory consumption per concurrent request, and denial-of-service exposure. Do not copy aggressive settings from another system without measuring them. Choose the strongest settings that the real login workload and infrastructure can safely support.

Verify the implementation with automated tests. Confirm that the correct password succeeds, an incorrect password fails, hashing the same password twice produces different encoded hashes because of different salts, both hashes still verify, outdated settings trigger password_needs_rehash(), current settings do not, malformed hashes fail safely, and passwords never appear in application logs.

1. Choose PASSWORD_ARGON2ID when it is available in the production PHP build; otherwise choose PASSWORD_DEFAULT.
2. Benchmark the selected algorithm and options on production-like hardware before fixing custom costs.
3. During registration or a password change, call password_hash() and store the complete returned string.
4. Do not create a manual salt, encrypt the password, or apply a fast general-purpose hash.
5. During login, retrieve the stored hash and call password_verify() with the submitted password.
6. Return the same general failure message for an unknown account and an incorrect password.
7. After successful verification, call password_needs_rehash() using the current algorithm and options.
8. If rehashing is required, generate a replacement hash and update it safely in the database.
9. Create the authenticated session and perform authorization as separate steps.
10. Apply rate limiting and monitoring, and log failures without passwords, hashes, or other secrets.
11. Test successful verification, rejection, unique salts, rehash detection, malformed input, concurrency behavior, and acceptable latency and memory use.

Common mistakes include storing plaintext passwords; using reversible encryption; using MD5, SHA-1, or a single SHA-256 or SHA-512 hash; adding a manual salt; truncating the encoded hash in the database; hashing the login input again and comparing strings; writing a custom verification comparison instead of using password_verify(); assuming Argon2id is available in every PHP build; hard-coding expensive Argon2id settings without benchmarking memory and concurrency; forgetting password_needs_rehash(); rehashing before the old password has been successfully verified; logging passwords or complete hashes; revealing whether an account exists; relying on hashing alone to stop online guessing; and treating authentication as authorization.

Start with password_hash(), password_verify(), and password_needs_rehash(). Explain that Argon2id is preferred when available and PASSWORD_DEFAULT is the portable fallback. Then cover automatic salts, why encryption and fast hashes are unsafe, safe failures, rehashing, benchmarking, logging without secrets, rate limiting, and the separation of authentication from authorization.

Prepared statements separate the SQL structure from user-supplied values. PHP sends values through placeholders, so the database treats them as data rather than executable SQL. They protect values only; dynamic table names, column names, and sort directions must be selected from strict allowlists.

This question asks how a PHP application can safely use information entered by a person when reading or changing stored records. The key idea is to keep the application's instruction separate from the entered information. If both are joined into one text string, a harmful entry may change the intended action. If they are supplied separately, the entry is handled only as information. Some choices, such as which field should control sorting, cannot be separated in the same way. Those choices must be limited to a fixed set approved by the developer.

Useful clarifying questions:

• Should I demonstrate PDO, MySQLi, or both?
• Should I cover dynamic columns, tables, and sort directions?
• Which database driver should I assume?

SQL injection occurs when untrusted input is inserted directly into an SQL string and is then interpreted as part of the SQL command. An attacker may use quotes, operators, comments, or additional SQL syntax to change the query's intended meaning.

A prepared statement separates:

1. The fixed SQL structure, such as SELECT id FROM users WHERE email = :email.
2. The data value supplied for the placeholder.

With PDO, PHP prepares the SQL statement and supplies the parameter value separately. When native prepared statements are used, the database receives the statement structure separately from its parameter values. The bound value is handled according to the placeholder position and parameter type. SQL-looking characters inside the value remain part of that value instead of becoming new SQL syntax.

Unsafe string concatenation looks like this:

$sql = "SELECT id FROM users WHERE email = '" . $email . "'";

If $email contains crafted input, it may terminate the quoted value and alter the SQL command.

The safe form uses a placeholder:

$statement = $pdo->prepare('SELECT id FROM users WHERE email = :email'); $statement->bindValue(':email', $email, PDO::PARAM_STR); $statement->execute();

PDO can emulate prepared statements for some drivers. Setting PDO::ATTR_EMULATE_PREPARES to false requests native preparation where the driver supports it. Correct parameterization remains essential either way, but native preparation more clearly preserves separation between the statement and its values and avoids some driver-specific emulation behavior.

Prepared-statement placeholders represent data values. They do not represent SQL identifiers or structural keywords. Therefore, a placeholder cannot safely choose a table name, column name, operator, or sort direction. For example, ORDER BY :column does not turn the supplied value into an identifier. The database generally treats it as a value, producing incorrect behavior rather than safely selecting a column.

For dynamic identifiers, map an external choice to a fixed developer-controlled value:

$allowedSortColumns = ['name' => 'name', 'created' => 'created_at'];

After confirming that the requested key exists, insert only the mapped constant into the SQL. Apply the same approach to table names and keywords such as ASC and DESC. Do not accept arbitrary identifier text and attempt to make it safe with filtering alone.

Input validation is still useful for business rules, such as requiring a valid email format or an integer within an expected range. However, validation is not a replacement for parameterized queries. A value can be valid for the application and still contain characters that would be dangerous if concatenated into SQL.

Use a least-privileged database account so the application can perform only the operations it requires. On failure, return a generic response to the client. Log an internal error code and safe diagnostic context, but do not log passwords, connection strings, session identifiers, access tokens, or unnecessary sensitive parameter values.

To verify the control, test normal values and hostile-looking values containing apostrophes, quotes, SQL comments, operators, and keywords. Confirm that each input is treated as one data value, does not change the query structure, and does not expose database error details. Also test that every unapproved identifier or sort direction is rejected before the SQL statement is built.

1. Write the SQL with placeholders for every untrusted data value.
2. Prepare the statement with PDO or MySQLi.
3. Bind each value using the appropriate parameter type, or pass values separately to execute.
4. Never concatenate untrusted values into the SQL structure.
5. For identifiers or SQL keywords that cannot use placeholders, map external choices to fixed values from a strict allowlist.
6. Execute with a least-privileged database account.
7. Return generic failure messages and log only non-sensitive diagnostic information.
8. Test normal, malformed, and malicious-looking values, and verify that rejected identifiers never reach SQL construction.

Common mistakes include concatenating or interpolating untrusted input into SQL, manually surrounding placeholders with quotes, treating input filtering or escaping as a complete defense, assuming validated data is safe to concatenate, attempting to bind table names or column names as parameters, accepting arbitrary ASC or DESC text, using an allowlist check but then inserting the original unchecked value, exposing database exception messages to clients, logging sensitive parameter values, and granting the application database account unnecessary permissions. Another mistake is claiming that prepared statements automatically secure SQL fragments that are still built through unsafe string concatenation.

Lead with the core rule: placeholders separate data values from SQL structure. Show one unsafe concatenation example and one parameterized PDO example. Then state the important limitation that identifiers and keywords cannot be bound and require fixed allowlists. Finish with validation, least privilege, safe failures, and a concrete verification test.

I prevent XSS by encoding untrusted data for its exact output context. I use htmlspecialchars() for HTML text and ordinary quoted attributes, validate URL schemes, avoid inline JavaScript data insertion, keep template auto-escaping enabled, and add a restrictive Content Security Policy as defense in depth.

This question asks how to stop information supplied by a visitor from becoming harmful instructions in another visitor's browser. The key is to handle the information safely at the place where it is displayed. Text, links, page properties, and browser instructions do not follow the same rules, so each needs suitable protection. Checking information when it enters the application is helpful, but that check cannot replace safe handling when displaying it. A complete answer should also cover safer page-building tools, extra browser restrictions, safe failure, careful records, and tests that prove the protection works.

Useful clarifying questions:

• In which contexts can user-controlled data appear: HTML text, attributes, URLs, JavaScript, CSS, or permitted HTML?
• Does the application use plain PHP templates or a template engine with automatic escaping?
• Are relative URLs or any schemes other than HTTPS required?
• Must users be allowed to submit limited HTML formatting?

The main rule is to encode untrusted data when it is rendered, using the encoder required by that exact browser context. Input validation should enforce business rules, such as expected length, type, format, and allowed values, but filtering or validation alone is not complete XSS protection.

For HTML text and ordinary quoted attributes, I use htmlspecialchars($value, ENT_QUOTES | ENT_SUBSTITUTE, 'UTF-8'). It converts characters such as <, >, &, single quotes, and double quotes into text that the HTML parser will not interpret as markup. ENT_SUBSTITUTE replaces invalid byte sequences safely. Attribute values must remain quoted. This rule does not make dangerous attributes such as onclick, style, or srcdoc safe, so I do not place untrusted data in those contexts.

A template engine should keep automatic escaping enabled by default. Developers should avoid raw-output features. When raw output is genuinely required, the value must come from a narrowly controlled source or be processed by a maintained, allowlist-based HTML sanitizer. A custom regular expression, strip_tags(), or a blacklist is not a reliable HTML sanitizer.

URLs require semantic validation as well as HTML encoding. I parse the URL and allow only the schemes the application needs, commonly https and, when justified, http. I reject unexpected schemes such as javascript: and data:. I then apply HTML attribute encoding when placing the accepted URL in a quoted href or src attribute. Encoding by itself cannot make a dangerous URL scheme safe. If relative URLs are allowed, I validate them with a separate policy instead of treating them as absolute URLs.

For JavaScript, I avoid placing user-controlled values directly inside inline scripts, event-handler attributes, or dynamically generated code. A safer design is to place serialized data in a non-executable data element and let trusted external JavaScript read it. When PHP must serialize data for an HTML script element, I use json_encode() with JSON_THROW_ON_ERROR, JSON_HEX_TAG, JSON_HEX_AMP, JSON_HEX_APOS, and JSON_HEX_QUOT. I never build JavaScript source by concatenating quoted user strings, and I do not pass untrusted strings to eval(), new Function(), or HTML-generating DOM APIs.

For CSS contexts, I avoid inserting user-controlled values into style attributes or style blocks. CSS has different parsing rules, and HTML encoding is not sufficient. I prefer selecting from predefined server-side values or applying a strict allowlist for a narrowly defined property.

Content Security Policy, or CSP, is a browser-enforced restriction on which scripts may run. A strong policy can block inline scripts, plugins, unsafe framing, and scripts from unapproved sources. Nonce-based or hash-based policies are stronger than allowing 'unsafe-inline'. CSP can reduce the impact of an encoding mistake, but it is defense in depth and never replaces context-aware output encoding.

When a value fails validation or cannot be encoded safely, the application should reject it or display a safe fallback instead of rendering the original value. Security logs can record the route, field name, validation reason, request identifier, and account identifier when appropriate. They should not contain passwords, session identifiers, authorization headers, private tokens, or unnecessarily complete attack payloads.

I verify the controls with automated tests containing HTML tags, closing tags, quote-breaking input, event handlers, dangerous URL schemes, malformed UTF-8, and strings containing </script>. I inspect the final browser DOM to confirm that values remain text or approved data, test the CSP response header, review CSP violation reports carefully, and use a security scanner as an additional check rather than as the only proof.

1. Inventory every location where user-controlled data is rendered.
2. Classify each location as HTML text, ordinary quoted attribute, URL, JavaScript data, CSS, or permitted HTML.
3. Validate the value against business rules and any context-specific allowlist.
4. Prefer redesigning the page when the destination context is dangerous, such as an event-handler attribute, inline CSS, or executable JavaScript.
5. Encode the value at output time with the correct context-specific method.
6. Keep template automatic escaping enabled and restrict raw-output operations.
7. Use a maintained allowlist-based sanitizer only when rendering user-authored HTML is an actual requirement.
8. Add a restrictive CSP as defense in depth.
9. Reject unsafe values or show a safe fallback, and log only non-secret diagnostic details.
10. Test malicious boundary cases and inspect the final DOM and security headers.

Common mistakes include treating input validation or filtering as complete protection; encoding data when it is stored instead of for its final output context; double-encoding or later decoding an already safe value; omitting ENT_QUOTES; leaving attributes unquoted; using HTML encoding inside event handlers, CSS, or JavaScript source; validating a URL's format but not its scheme; allowing javascript: or unnecessary data: URLs; inserting PHP values directly into JavaScript strings; using innerHTML when textContent is sufficient; using strip_tags(), a blacklist, or regular expressions as an HTML sanitizer; disabling template auto-escaping; marking untrusted content as raw; relying only on CSP; weakening CSP with broad sources or 'unsafe-inline'; and logging secrets or complete malicious payloads unnecessarily.

Start with one sentence: encode at output time for the exact browser context. Then distinguish HTML text, URLs, JavaScript, and permitted HTML. State clearly that validation and CSP are supporting controls, not substitutes for context-aware encoding.