Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Disabled archives should 404 and not 301 redirect to home page #21795

Open
5 tasks done
kkmuffme opened this issue Nov 5, 2024 · 2 comments
Open
5 tasks done

Disabled archives should 404 and not 301 redirect to home page #21795

kkmuffme opened this issue Nov 5, 2024 · 2 comments

Comments

@kkmuffme
Copy link
Contributor

kkmuffme commented Nov 5, 2024

  • I've read and understood the contribution guidelines.
  • I've searched for any related issues and avoided creating a duplicate issue.

Please give us a description of what happened

Disabling archives (e.g. author archives /wp-admin/admin.php?page=wpseo_page_settings#/author-archives) will mean that the author archive page + all feeds of it will 301 redirect to home page instead of 404.

  1. Server load: it unnecessarily creates server load even when served from page cache (since we need to serve 2 requests as we first need to serve the 301 and then the home page), and the author and feed pages are requested gazillions of times by various bots
    For WP installs that do not cache 301s (which are 99% of WP sites I'd guess), it's even worse, since it massively increases the server load since the disabled archives wouldn't be served from page cache
    (and WP pages without page even worse, since it's effectively serving 2 uncached requests)

  2. Security: this feature accidentally creates a side-channel attack.
    e.g. you have an existing user John. Disabling the author archives will then mean:
    /author/John/ => redirected to home page, 301
    /author/Robert/ => this user does not exist, 404

Now this by itself already could be abused for side-channel attacks, since it allows us to easily circumvent login restrictions. e.g. I have a list of usernames+passwords from a leak, but I cannot try all of them, since most pages rate limit invalid logins. I can now use this inconsistent behavior to validate the usernames and then only try the valid usernames for login.

Even worse, when using a security plugin that also disables this archives but serves them as 404 - usually Yoast would intercept it earlier and force the 301, which means that unsuspecting users accidentally make their page less secure by disabling the archives with Yoast in this case.

Additionally, this allows checking if a specific person has an account on a page (which I guess is one of the reason many sites disable those, since it creates unnecessary data privacy requirements)

  1. you yourself think 301 instead of 404 is a bad idea: https://yoast.com/seo-anti-patterns-301-redirect-all-your-404s-to-your-homepage/

To Reproduce

Step-by-step reproduction instructions

  1. disable author archives on /wp-admin/admin.php?page=wpseo_page_settings#/author-archives
  2. assuming your username is John, open /author/John/ => redirects to home page

Expected results

404

Actual results

301 to home page

Technical info

  • Which browser is affected (or browsers):
  • Chrome
  • Firefox
  • Safari

Used versions

  • WordPress version: 6.6.x
  • WordPress Theme: twentytwentyfour
  • Yoast SEO version: 23.7
  • Relevant plugins in case of a bug: wordpress-seo
@kkmuffme
Copy link
Contributor Author

kkmuffme commented Nov 5, 2024

This same issue also exists for the other archives.

For media it redirects to the actual image isntead of 404-ing (as it says there), however I think the more efficient (and preferred, or in that case possibly optional) way would be to just 404 it too.

@josevarghese
Copy link
Contributor

Hi @kkmuffme

Thanks for using the Yoast SEO plugin and creating the bug report. We are discussing this issue internally and will update you with more details.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants