WordPress heartbeat api security: What Is the WordPress Heartbeat API?
Every WordPress admin dashboard runs a background process called the Heartbeat API. It sends AJAX requests from the browser to the server every 15 to 60 seconds. This constant polling checks for post lock status, auto-save triggers, and session expiration. It runs on every admin page by default, and it runs often.
The Heartbeat API was introduced in WordPress 3.6 to make the editing experience smoother. When two users edit the same post, Heartbeat notifies the second user that someone else holds the lock. It also powers the auto-save feature so you never lose more than a few keystrokes. In theory, it is a helpful tool. In practice, it creates a persistent connection between every open admin tab and your server, and that connection has security implications.
Developers can hook into Heartbeat with custom JavaScript and server-side filters. This flexibility makes it a popular tool for real-time dashboard updates, notifications, and custom admin panels. But flexibility also means more surface area for attackers. Every AJAX endpoint that Heartbeat exposes is a potential entry point if not properly secured.
WordPress heartbeat api security: How Heartbeat Expands the Attack Surface
Each Heartbeat request hits admin-ajax.php. This file handles all authenticated AJAX calls in WordPress. Because Heartbeat fires so frequently, it multiplies the number of requests an attacker can send without triggering rate limits. A single tab sends one request every 15 seconds. Four tabs send four requests every 15 seconds. Scale that up, and the server sees a flood of traffic that looks legitimate.
The Heartbeat API exposes data in the response object. Plugins and themes often add custom data to Heartbeat responses without proper capability checks. A poorly coded plugin might leak user data, site options, or nonce values through Heartbeat. Once an attacker identifies these leaks, they can harvest information across multiple sessions with minimal effort.
Another concern is nonce reuse. Heartbeat regenerates nonces on each tick, but some implementations store and reuse old nonces. An attacker who intercepts a Heartbeat response can replay that nonce against other AJAX handlers. This kind of attack is rare, but the Heartbeat API makes it easier to execute because of the sheer volume of requests flying back and forth.
Post Locking Risks and Exploitation Vectors
WordPress uses the Heartbeat API to manage edit locks. When you open a post for editing, Heartbeat sends a lock request to the server. The server marks that post as locked by your user ID. Other users see a notice that the post is currently being edited. This prevents conflicting saves and lost work.
The lock mechanism works through Heartbeat’s wp-refresh-post-lock and wp-check-locked-posts events. If an attacker can spoof these events, they can lock other users out of posts. They can hold a post hostage by sending fake lock requests faster than the legitimate editor. This is a disruption tactic, but it can also hide malicious edits made to the post while the editor waits for the lock to release.
Exploiting post locking requires authenticated access, so this is not a vulnerability for unauthenticated attackers. But in a multi-author environment, a compromised editor account can cause significant damage. An attacker can lock critical posts, prevent publishing, and create confusion. The Heartbeat API provides the mechanism, and the lock management logic trusts the sender by default.
Denial of Service Potential Through Heartbeat
The most immediate risk with the Heartbeat API is resource exhaustion. Each Heartbeat request consumes PHP memory, database query time, and CPU cycles. On a shared server or a budget host, a few concurrent Heartbeat requests can slow the entire site to a crawl. This affects both the admin area and the public-facing site.
Consider a scenario where an editor leaves five browser tabs open overnight. Each tab fires Heartbeat every 15 seconds. That is 20 requests per minute from a single user. Multiply that by ten editors, and you have 200 extra requests per minute hitting your server. None of these requests serve content to visitors. They all burn resources just to maintain edit locks and nonce caches.
An attacker can weaponize this by opening multiple admin sessions. If they compromise a single low-privilege account, they can open dozens of tabs and drive up server load. This kind of attack is hard to distinguish from normal behavior because each individual request is legitimate. The cumulative effect, however, can take down a site. Mitigating this requires controlling how often Heartbeat fires and who can use it.
How to Limit the Heartbeat API Interval
WordPress provides a constant to control the Heartbeat interval. Add this line to your wp-config.php file to set a slower tick rate:
define( 'WP_HEARTBEAT_INTERVAL', 60 );This changes the default interval from 15 seconds to 60 seconds. It reduces the total number of requests by 75 percent. The minimum allowed value is 15, and the maximum is 60. Setting it higher than 60 has no effect because WordPress caps it internally. This approach is site-wide and applies to all users regardless of role.
For more granular control, use the heartbeat_settings filter in your theme’s functions.php file:
add_filter( 'heartbeat_settings', 'trusti_modify_heartbeat_interval' );
function trusti_modify_heartbeat_interval( $settings ) {
$settings['interval'] = 60;
return $settings;
}This filter runs on the JavaScript side and controls how often the browser sends Heartbeat requests. It is useful when you want different intervals for different conditions, but keep in mind that the interval cannot go below 15 seconds on the server side. The combination of the constant and the filter gives you full control over the polling frequency.
How to Disable Heartbeat Selectively
Not every admin page needs the Heartbeat API. The post editor needs it for lock management. The dashboard usually does not. You can disable Heartbeat on a per-page basis using the wp_enqueue_scripts action combined with the heartbeat_enqueue script handle:
add_action( 'wp_enqueue_scripts', 'trusti_disable_heartbeat_dashboard' );
function trusti_disable_heartbeat_dashboard() {
if ( ! current_user_can( 'edit_posts' ) ) {
wp_deregister_script( 'heartbeat' );
}
}This example removes the Heartbeat script for users who cannot edit posts. You can expand the condition to target specific admin pages. Use get_current_screen() to check the current admin page and disable Heartbeat everywhere except the post editor. This preserves lock functionality while eliminating unnecessary requests on other pages.
For role-based control, check the user’s capabilities before enqueuing Heartbeat:
add_action( 'admin_enqueue_scripts', 'trusti_heartbeat_by_role' );
function trusti_heartbeat_by_role() {
$user = wp_get_current_user();
if ( in_array( 'subscriber', (array) $user->roles ) ) {
wp_deregister_script( 'heartbeat' );
}
}This approach is ideal for membership sites or client portals where non-admin users log into the dashboard. Subscribers and customers do not need Heartbeat running in their admin area. Removing it for them cuts down on server load and reduces the attack surface without affecting the editorial workflow for your content team.
Do It All With One Plugin
Managing Heartbeat manually through code works, but it requires maintenance across theme updates and site migrations. A dedicated security plugin gives you a unified dashboard to control Heartbeat behavior, monitor unusual request patterns, and block suspicious activity before it escalates.
Trusti Security monitors admin activity across your WordPress installation, including plugin installations, user logins, content changes, and settings modifications. The audit log provides a complete history of who did what and when. Instead of patching individual filters in functions.php, you get a visual interface with real-time alerts and one-click controls.
For a deeper look at securing your WordPress admin area, check out our guide on WordPress login security best practices. Combined with Heartbeat control, a strong login policy creates a much harder target for attackers. The goal is to layer multiple defenses so that no single feature becomes a weak point.
The Bottom Line
The WordPress Heartbeat API is a useful feature that comes with hidden costs. It enlarges the attack surface, enables post lock exploitation in multi-author environments, and creates a real DoS risk when left unchecked. Most site owners do not realize how many requests their admin area generates until they check their server logs and see the volume.
Controlling the Heartbeat API does not require disabling it entirely. Set a reasonable interval, restrict it to pages that actually need it, and remove it for user roles that do not require it. The code snippets in this article give you a starting point that works on any WordPress site regardless of hosting environment.
Security is about reducing risk without breaking functionality. The Heartbeat API offers a clear example of this balance. With a few lines of code or a dedicated plugin, you can keep the features you need while closing the gaps that attackers look for. Audit your Heartbeat usage today and tighten the settings before they become a problem you have to react to.