Put defined(‘ABSPATH’) || exit; at the top of every PHP file you write. Without it, anyone can request that file directly and run it outside WordPress, where none of your assumptions hold.
WordPress files live under the web root, which means a browser can request any of them by URL. A theme or plugin PHP file requested directly executes without WordPress loaded — no functions defined, no user logged in, no permission checks — and whatever it does at the top level runs.
Most of the time this produces a fatal error and a stack trace, which leaks your paths. Sometimes it produces something worse.
Table of contents
- The guard
- What can go wrong without it
- Server-level protection for the files that matter
- No PHP execution in uploads
- Serving files only to people entitled to them
- Getting to the files in the first place
- How this fits the rest of the stack
- FAQ
The guard
The idiom, on the first line of every PHP file:
<?php
defined( 'ABSPATH' ) || exit;ABSPATH is defined by wp-load.php early in WordPress’s bootstrap. If it is not defined, WordPress did not load this file — the request came directly — and the script stops before doing anything.
You will see several spellings, all equivalent:
defined( 'ABSPATH' ) || exit;
if ( ! defined( 'ABSPATH' ) ) { exit; }
if ( ! defined( 'ABSPATH' ) ) { die( 'No direct access' ); }The first is what core and most well-maintained plugins use. Avoid the version with a message — it confirms to a prober that the file exists and is guarded, where a blank response tells them nothing.
This goes in every PHP file: the main plugin file, includes, class files, template parts, functions.php. The cost is one line and there is no case where it hurts.
What can go wrong without it
The severity depends on what the file does at the top level.
Best case: a fatal error, because the file calls a WordPress function that does not exist. The visitor sees an error, and if WP_DEBUG is on in production — which it should not be — they see your absolute server paths.
Worse: the file defines a class or function with no side effects and returns a blank page. Harmless, and it confirms the file exists, which helps someone enumerate your plugin versions against known advisories.
Bad: the file performs an action at the top level. An include that processes $_POST, writes a file, or queries the database now runs with no authentication — because current_user_can() does not exist to be called, and the capability check you thought protected it was in a different file.
That last case is the real vulnerability class, and it is common in AJAX handlers and form processors written as standalone files. The guard is a one-line fix for it.
Server-level protection for the files that matter
Some files should never be served regardless of what PHP does. Block them at the web server.
Apache, in the site’s .htaccess:
# wp-config.php
<Files wp-config.php>
Require all denied
</Files>
# Dotfiles and version control
<FilesMatch "^\.">
Require all denied
</FilesMatch>
# Logs, backups, SQL dumps left behind by a migration
<FilesMatch "\.(log|sql|bak|old|swp|env)$">
Require all denied
</FilesMatch>
# Block xmlrpc.php if you do not use it
<Files xmlrpc.php>
Require all denied
</Files>Nginx, in the server block:
location ~* /(?:wp-config\.php|readme\.html|license\.txt) {
deny all;
}
location ~ /\. {
deny all;
}
location ~* \.(log|sql|bak|old|env)$ {
deny all;
}The .sql and .bak rules earn their place more often than people expect. Migration tools and manual backups leave database dumps in the web root, and a dump served over HTTP is every password hash and every piece of customer data in one file.
No PHP execution in uploads
This is the highest-value rule on the list. If an attacker can get a PHP file into wp-content/uploads — through a vulnerable plugin’s upload handler, a compromised account, or a file-type check that only inspected the extension — they have a shell, unless the server refuses to execute PHP there.
Apache, in wp-content/uploads/.htaccess:
<Files *.php>
Require all denied
</Files>Nginx:
location ~* /wp-content/uploads/.*\.php$ {
deny all;
}Nothing legitimate executes PHP from the uploads directory, so this rule has no downside and converts a successful upload exploit from a full compromise into an inert file sitting on disk.
Worth applying the same rule to any other writable directory — cache folders, plugin-created upload paths, temporary directories.
Serving files only to people entitled to them
A different problem often confused with this one. Files in wp-content/uploads are served directly by the web server, so a PDF attached to a members-only page is available to anyone with the URL. WordPress never sees the request and cannot check permissions.
The fix is to stop serving those files directly. Store them outside the web root, and serve them through a PHP endpoint that checks permission first:
add_action( 'init', function () {
if ( ! isset( $_GET['secure_file'] ) ) {
return;
}
if ( ! is_user_logged_in() || ! current_user_can( 'read_private_docs' ) ) {
wp_die( 'Not authorised', 403 );
}
$name = basename( wp_unslash( $_GET['secure_file'] ) ); // strip any path
$path = WP_CONTENT_DIR . '/private-files/' . $name;
if ( ! file_exists( $path ) ) {
wp_die( 'Not found', 404 );
}
header( 'Content-Type: ' . mime_content_type( $path ) );
header( 'Content-Disposition: attachment; filename="' . $name . '"' );
readfile( $path );
exit;
} );The basename() call is not optional — without it, ?secure_file=../../wp-config.php is a directory traversal that serves your database credentials. Any code building a path from user input needs that treatment.
This is the pattern that membership and download plugins implement, and it is worth understanding even if you use one, because the security depends on the files genuinely being outside the directly-served path.
Getting to the files in the first place
Applying most of this means editing files on the server — adding an .htaccess to uploads, checking whether a stray .sql dump is sitting in the web root, reviewing what a plugin dropped into wp-content.
On most hosts that means SFTP credentials and a client, which is enough friction that these checks get postponed indefinitely.
Managed WordPress on RunxBuild includes a file manager in the dashboard — browse, edit, upload, unzip and download — and a database browser for tables, rows and SQL, so auditing what is actually in the web root and adding a rule to a directory is something you do in the browser rather than something you schedule.
How this fits the rest of the stack
defined( 'ABSPATH' ) || exit; on every PHP file, no PHP execution in uploads, server rules blocking config files and stray SQL dumps, and permission-checked delivery for files that should not be public. The uploads rule in particular converts a whole class of exploit into a harmless file on disk. Managed WordPress with a dashboard file manager makes these checks routine — the RunxBuild hosting calculator shows what those plans cost.
Useful related references:
- Squarespace vs WordPress: The Question Behind the Question
- WordPress Maintenance Services: What You Are Actually Paying For
- WP-CLI: The Commands That Make WordPress Administration Bearable
- Services on RunxBuild
FAQ
What does defined ABSPATH exit do in WordPress?
It stops a PHP file from running when requested directly. ABSPATH is defined during WordPress’s bootstrap, so if it is missing the file was not loaded by WordPress and the script exits before executing anything.
Where should I put the ABSPATH check?
On the first line after the opening PHP tag, in every PHP file you write — the main plugin file, includes, class files, template parts and functions.php. It costs one line and there is no case where it causes harm.
How do I stop PHP running in the uploads folder?
Add an .htaccess in wp-content/uploads with a <Files *.php> deny rule on Apache, or a location ~* /wp-content/uploads/.*\.php$ { deny all; } block on Nginx. Nothing legitimate executes PHP there, and it neutralises a successful malicious upload.
How do I protect files that only logged-in users should download?
Store them outside the directly-served uploads directory and serve them through a PHP endpoint that checks capability first, then reads the file. Always run the requested filename through basename() or a directory traversal will expose wp-config.php.
Is blocking direct access enough to secure WordPress?
No. It closes one class of problem. You also need current core, themes and plugins, strong authentication, correct file permissions, no stray database dumps in the web root, and backups you have tested restoring.