Summary

A CORS misconfiguration vulnerability exists in default installations of Strapi where attacker-controlled origins are improperly reflected in API responses.

Technical Details

By default, Strapi reflects the value of the Origin header back in the Access-Control-Allow-Origin response header without proper validation or whitelisting.

Example: Origin: http://localhost:8888 Access-Control-Allow-Origin: http://localhost:8888 Access-Control-Allow-Credentials: true

This allows an attacker-controlled site (on a different port, like 8888) to send credentialed requests to the Strapi backend on 1337.

Suggested Fix

1. Explicitly whitelist trusted origins
2. Avoid reflecting dynamic origins

Summary

Strapi's password hashing implementation using bcryptjs lacks maximum password length validation. Since bcryptjs truncates passwords exceeding 72 bytes, this creates potential vulnerabilities such as authentication bypass and performance degradation.

POC

Create an admin user with a password exceeding 72 characters like 85, Log in using only the first 72 characters of the password. Authentication is successful, confirming the issue.

Proposed Solution Based on discussions:

Add a maximum password length validation (72 characters) during password creation and updates for both Admin and U&P users. Truncate passwords exceeding 72 bytes on the server before passing them to bcryptjs during login. Optionally, issue a warning to users with passwords longer than 72 bytes during login, informing them of truncation.

Impact

This issue affects all Strapi installations using bcryptjs for password hashing. Until resolved, it can lead to: Authentication Bypass: Users may unknowingly set passwords exceeding 72 bytes, leading to truncated, predictable hashes. Performance Issues: Excessively long passwords can degrade server performance.