Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallSome links on this page are affiliate links: if you buy through them we may earn a commission, at no extra cost to you.
Prevent SQL injection in WordPress by using built-in WordPress APIs whenever possible and, for custom SQL, passing every data value through $wpdb->prepare() with the correct placeholder. Never concatenate untrusted input into a query. For LIKE searches, escape the search text with $wpdb->esc_like() before preparing it; for identifiers and sort directions, use a strict allow-list.
Prefer WordPress APIs over handwritten SQL
When a WordPress function supports the operation, use it rather than constructing SQL yourself. The WordPress security handbook puts it plainly: “The first rule for hardening your theme against SQL Injection is: When there’s a WordPress function, use it.” See the WordPress security hardening handbook.
Using native APIs reduces the amount of query construction your code must get right. If a custom query is necessary, use WordPress’s database abstraction and parameterize every value.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Use $wpdb->prepare() for custom query values
$wpdb->prepare() separates SQL structure from data by substituting typed placeholders. The documented placeholders are %d for integers, %f for floats, %s for strings, and %i for identifiers. Keep placeholders unquoted in the query template. WordPress documents the method and placeholder behavior in its wpdb::prepare() reference.
#1 Best Overall
$sql = $wpdb->prepare(
"SELECT id FROM {$wpdb->posts} WHERE post_author = %d AND post_title = %s",
$author_id,
$title
);
$rows = $wpdb->get_results($sql);Here, the author ID and title are data supplied separately from the SQL structure. Do not interpolate or concatenate values from requests, forms, cookies, REST requests, or shortcodes into query strings. OWASP explains that injection risks arise when applications build dynamic queries by concatenating untrusted input, and recommends prepared statements to keep code and data separate: OWASP SQL Injection Prevention Cheat Sheet.
Handle LIKE searches, identifiers, and sort clauses separately
LIKE searches
For a search pattern, first call $wpdb->esc_like() on the user-provided search text. Then add the % wildcard characters to that escaped value and pass the completed pattern as a %s argument to $wpdb->prepare(). WordPress warns that reversing the order is very bad for security. See wpdb::esc_like().
$pattern = '%' . $wpdb->esc_like($search_text) . '%';
$sql = $wpdb->prepare(
"SELECT id FROM {$wpdb->posts} WHERE post_title LIKE %s",
$pattern
);Table names and column names
Do not let arbitrary input choose a table or column. Map input to a small set of identifiers that your code explicitly permits. WordPress added the %i identifier placeholder in WordPress 6.2, but it does not decide which identifiers your application should allow. Combine it with an allow-list when a query needs a dynamic identifier.
ORDER BY and other SQL syntax
Sort directions such as ASC and DESC, and SQL fragments such as ordering clauses, are query syntax rather than ordinary data values. Do not insert user-provided text directly into them. Accept only known options, such as mapping a requested sort key to a fixed column and mapping a direction to either ASC or DESC. Value placeholders do not make arbitrary SQL syntax safe.
Why esc_sql() is not a substitute for prepare()
esc_sql() has a narrower role: it escapes values intended for quoted SQL contexts. It does not make unquoted numeric fragments, field names, keywords, or arbitrary ORDER BY input safe. Prefer $wpdb->prepare() for values, and allow-list identifiers and syntax. See the WordPress esc_sql() reference.
Validation can add a useful second layer—for example, rejecting a sort option that is not one of the expected choices—but it does not replace parameterization. OWASP recommends allow-list validation alongside prepared statements and strongly discourages relying on escaping all input as the primary defense.
Quick Recap
Review and maintain WordPress SQL code
- Keep WordPress, plugins, and themes updated. WordPress 4.8.3 shipped hardening after unsafe
prepare()behavior affected WordPress 4.8.2 and earlier and could expose vulnerable plugin or theme code paths. The release details are in the WordPress 4.8.3 security release notes. - Search custom PHP for risky query construction. Look for SQL strings built with concatenation or interpolation, especially where values originate from requests, forms, cookies, REST endpoints, or shortcodes.
- Replace custom SQL when a native API covers the operation. For queries that must remain custom, ensure every data value goes through
$wpdb->prepare(). - Check placeholder types and quoting. Match values to
%s,%d, or%f; use%ifor identifiers where supported, and leave placeholders unquoted in the template. - Inspect special query parts independently. Review
LIKEpatterns, identifiers, sort clauses, and any limit construction rather than assuming value escaping covers them. - Review component maintenance. Keep plugins and themes current and remove components that are no longer maintained or needed.
- Check behavior in code review. Verify that attacker-controlled strings remain data and cannot change the query structure. This is an engineering review check, not a substitute for testing the application in its deployment context.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Recommended Free Tools
