Just about everything should be https now.

I just examined the 5.2.3 php files (844 files with 365741 non-blank lines -- yikes!!) and found several references that might be real. I say "might" be because it is difficult to know what becomes of an http url being built deep in some php function. I'm just starting out in WordPress and php so it's a little bit over my head now.

As an example, in wordpress/wp-activate.php are the lines:

printf(
    /* translators: 1: site URL, 2: username, 3: user email, 4: lost password URL */
    __('Your site at %1$s is active. You may now log in to your site using your chosen username of &#8220;%2$s&#8221;. Please check your email inbox at %3$s for your password and login instructions. If you do not receive an email, please check your junk or spam folder. If you still do not receive an email within an hour, you can <a href="%4$s">reset your password</a>.'),
    sprintf('<a href="http://%1$s">%1$s</a>', $signup - > domain),
    $signup - > user_login,
    $signup - > user_email,
    wp_lostpassword_url()
);

where in the sprintf() appears that the site url is formed using http://. This code is living inside two else clauses and, for all I know, might only get here if the site is detected as running with http.

Has the WordPress codebase been audited for the presence of insecure http: URLs?

Just about everything should be https now.

I just examined the 5.2.3 php files (844 files with 365741 non-blank lines -- yikes!!) and found several references that might be real. I say "might" be because it is difficult to know what becomes of an http url being built deep in some php function. I'm just starting out in WordPress and php so it's a little bit over my head now.

As an example, in wordpress/wp-activate.php are the lines:

printf(
    /* translators: 1: site URL, 2: username, 3: user email, 4: lost password URL */
    __('Your site at %1$s is active. You may now log in to your site using your chosen username of &#8220;%2$s&#8221;. Please check your email inbox at %3$s for your password and login instructions. If you do not receive an email, please check your junk or spam folder. If you still do not receive an email within an hour, you can <a href="%4$s">reset your password</a>.'),
    sprintf('<a href="http://%1$s">%1$s</a>', $signup - > domain),
    $signup - > user_login,
    $signup - > user_email,
    wp_lostpassword_url()
);

where in the sprintf() appears that the site url is formed using http://. This code is living inside two else clauses and, for all I know, might only get here if the site is detected as running with http.

Has the WordPress codebase been audited for the presence of insecure http: URLs?

• security
• https
• http

Share Improve this question asked Sep 5, 2019 at 20:19 President James K. PolkPresident James K. Polk 10122 bronze badges

Add a comment  | 

1 Answer 1

Sorted by: Reset to default 2

Searching for non-SSL references in the code base is a smart idea and you should probably report any you find on hackerone (the place to disclose WordPress vulnerabilities).

I also suggest you review the WordPress Security page on wordpress.

To answer your question, I would say WordPress has been audited extensively for various security vulnerabilities by both the internal WordPress team and countless number of external security experts as evidenced by the authors of reports on Hackerone. You can see a list of security updates here. I reviewed the most recent security updates (going back to the 4.7 branch, January of 2017) and found the following references to SSL and HTTPS:

• Use safe redirects when redirecting the login page if SSL is forced
• Insufficient redirect validation in the HTTP class

It's very possible that no, non-HTTPS scans have been conducted or acted on but that is probably intentional as, although the majority of public sites are on HTTPS, there may still be millions that aren't and forcing SSL where it isn't supported would break people's sites. Also, many, possibly most, developers don't use SSL on their local machines. Forcing SSL in this situation (a local development machine) would also cause issues for developers working on their local machines.

Perhaps the most revealing search, however, is on the WordPress core on https://core.trac.wordpress/search?q=ssl There you can see lots of tickets and diffs addressing insecure schemes. Still, however, I have been unable to find one that explicitly addresses the issue of non-HTTPS schemes.

So, I have not been able to find evidence of a specific audit of non-HTTPS URLs but I have found evidence of insecure redirects being addressed in security updates.

On a side note, I personally would try to avoid calling HTTP (no S) insecure. It is simply a protocol and actually still has a purpose in this world - less every day but it is still used and fit for purpose.