Like the blog? Get the book »

Fix Site Health Error: The authorization header is missing

Fix Site Health Error: The authorization header is missing

Quick post that explains how to fix the error, “The authorization header is missing”. This error may be found under “recommended improvements” in the WordPress Site Health tool (located under the WP menu ▸ Tools ▸ Site Health).

When running a Site Health check, the “authorization header” warning happens when you’ve upgraded WordPress (to version 5.6 or better) and have Permalinks enabled, but the site’s .htaccess rules have not been updated with the latest. This DigWP tutorial explains what’s happening and shows how to fix the error easily with a few clicks.

The authorization header is missing.


The solution

When testing your WordPress with the Site Health tool, if you get this:

Site Health Results: Authorization Header MissingWP menu ▸ Tools ▸ Site Health — The authorization header is missing. Click for full-size image.

If you click the error and toggle it open, you’ll get a bit more information: “The Authorization header comes from the third-party applications you approve. Without it, those apps cannot connect to your site.” Screenshot:

Site Health Results: Authorization Header Missing (Details)Details about the authorization-header error. Click for full-size image.

This error means that your WordPress Permalink rules are not up-to-date. To fix the issue, you need to update the Permalink rules in your site’s .htaccess file. There are several ways to do this:

  • Easy — Visit your Permalink settings and click “Save Changes”
  • Manual — Manually update .htaccess with current Permalink rules

So try the easy method first. If it works, then stop; you’re done. If it does not work, the “manual” method definitely should resolve the issue. Let’s walk through each of these solutions..

Flush Permalinks

The easiest way to fix the authorization-header issue, is to click on the “Flush permalinks” link, which is displayed right there on the Site Health screen. Here is a screenshot:

Authorization Header Missing: Flush PermalinksShowing the location of the “Flush permalinks” link. Click for full-size image.

That will take you to the WordPress Permalinks settings. This is where you can “flush” (i.e., update) your site’s Permalink rules. You can do this by clicking the “Save Changes” button as shown here:

Permalink settings showing Save Changes buttonPermalink settings showing the “Save Changes” button. Click for full-size image.

You do NOT need to make any actual changes to any Permalink settings. All you need to do is click “Save Changes” and done. Once you do that, WordPress will attempt to update the site’s .htaccess file with the latest/current Permalink rules. Thus solving the authorization-header issue. You can verify the fix by running a fresh Site Health test.

Important! Updating/flushing Permalink rules via the Admin Area results in changes made to the .htaccess file on the server. Flushing does not affect the local copy of your .htaccess file. So make sure to update both local and server copies to avoid having to go through this again in the future.

Manually update .htaccess

If the easy method does not work to resolve the “authorization header is missing”, you will need to update your Permalink rules manually. To do it, open your site’s .htaccess file. Look for a block of code that begins with this line:

# BEGIN WordPress

..and ends with this line:

# END WordPress

Located between these two lines are the WordPress Permalink rules. Whatever you have there, you want to replace with the latest set of rules. You can find the current rules at So grab a copy of the correct rules for your site (Basic or Multisite), and replace your existing rules via copy/paste. Save the file, upload, and done.

That should resolve the Site Health authorization-header issue. To verify success, try another test with the Site Health tool.

If after updating your Permalink rules, Site Health continues to show the error, most likely there is something else that is interfering with normal functionality. In this case you may contact your support team. Or if you’re savvy, follow our Troubleshooting Guide to help diagnose and resolve any outstanding issues.

About the error

So what causes the “authorization header” error? WordPress version 5.6 introduces Application Passwords. This feature enables authenticated users and apps to interact with your site. Application Passwords started as an awesome free plugin that could be added to any WordPress site as needed. Now it’s been integrated into WordPress core so all sites must have it, whether needed or not.

DigWP Tip: If you have no need for Application Passwords, you can disable them easily with my free plugin, Disable Application Passwords.

WordPress users may be familiar with the new “Application Passwords” settings that are displayed on the Profile screen of every registered user. If you have yet to check it out, go take a look at the bottom of any “Edit User” screen. Here is a screenshot of how it looks in WordPress 5.6:

Application Passwords SettingsWP menu ▸ User Profile/Edit User ▸ Application Passwords settings. Click for full-size image.

That’s all great, but what most WordPress users probably are not aware of, is that the new Application Passwords feature brings changes to the WordPress Permalink rules located in the site’s .htaccess file. The changes are required for WordPress and Application Passwords to work properly.

.htaccess changes in WP 5.6

Here is the new line that is added to WordPress Permalink rules (via .htaccess) in version 5.6:

RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

This line helps to handle the Authorization header for HTTP requests coming from any approved third-party applications. Without proper handling of the Authorization header, apps will not be able to connect with your site.

So for sites using outdated Permalink rules, the above new line will be missing from .htaccess. This causes errors when WordPress tries processing requests. The Site Health error happens because WordPress expects certain authorization headers that are not included with the request.

As of now, here is what the WordPress Permalink rules look like in the site’s .htaccess file:

# BEGIN WordPress
# The directives (lines) between "BEGIN WordPress" and "END WordPress" are
# dynamically generated, and should only be modified via WordPress filters.
# Any changes to the directives between these markers will be overwritten.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

# END WordPress

Notice the E=HTTP_AUTHORIZATION rule added right up front there. When that line is included as shown here, the Site Health “authorization header” error should not happen.

DigWP Tip: For a complete guide to Apache/.htaccess, check out my book .htaccess made easy. Features an entire chapter covering all things WordPress :)

17 responses

  1. Thank you for this really helpful article. I seem to have a tricky situation on my website. The easy fix didn’t make the Site Health warning disappear. So I took a look at the htaccess file inside my WordPress site’s root folder on my hosting server, and it has the most up-to-date rules already. Do you know of any other reasons why I’m still seeing this error?

    Your article mentioned needing to update the htaccess file on the server and local copy. What does local copy mean exactly, and how do I update the local copy? Thank you!

    • Hi Heather, the server copy is used when someone visits your site online. If you have a local copy, like for SFTP or similar, then you would know about it. If not, maybe ask whoever is managing your site. Not all sites have a local copy, so no worries if you don’t have one, just make sure the rules on the server copy are current.

  2. Thanks for this article! I’m also getting that same site health error, have flushed the permalinks, and have the correct code in my .htaccess file. Yet I still get the site health error. Any ideas of how to continue troubleshooting?

  3. Just FYI:

    I tried both of these solutions and neither one worked. I added the line below to .htaccess and that was the remedy.

    SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1
  4. Thanks for sharing adding: SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1 to WordPress section in htaccess worked for me too.

  5. The first one is not worked for me. But the second one is worked for my site. I think the second one is better. However thanks a lot @Jeff.

  6. This was helpful-ish. I’m actually not seeing the Application Passwords. I’m running WP 5.7 on all my sites now.

    Server architecture Linux 4.4.260-icpu-064 x86_64
    Web server Apache (should be running 2.4.38)
    PHP version 7.4.16 (Supports 64bit values)

    Now I’m thinking I should install that Application Password plugin? How can it be completely missing from the latest version of WP and causing issues?

  7. Okay – I don’t know what’s going on with my 5.7 install and the Application Password thingy but I did install the Deactivate Application Passwords and aside from some still stray ERR_CONNECTION_RESETS in my console I’m not getting “page cannot be loaded” screens of death.

    I’ve Googled this a bit but can’t find why this is happening to me.

  8. I tried to add the code SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1 but when I go back and check my file the information has been overwritten.

Comments are closed for this post. Contact us with any critical information.
© 2009–2024 Digging Into WordPress Powered by WordPress Monzilla Media shapeSpace