Security

How can I enable MFA for administrator login? like: email token link third party authenticator

I think it would be very easy to add something like TOTP 2FA (EG google authentication) http://www.passportjs.org/packages/passport-2fa-totp/

If you're building an API which needs a high-security level, it can be very useful to use a 2FA. We could pretty easily support two-factor authentication using the current implementation of the Users & Permissions plugin. For more details, please see https://github.com/strapi/strapi/issues/786

The current implementation only supports one provider by user. This feature will allow your user to support multiple authentication providers like Google and Twitter for the same user. Related issue: https://github.com/strapi/strapi/issues/2468

Referencing to: https://github.com/strapi/strapi/security/advisories/GHSA-g637-9xhc-39qf Currently the initial configuration for strapi is not secure (using wildcard with allow-credential). After discussed with strapi security team, we agreed that this is operator responsibility. However, the current state, the strapi still allows insecure configuration to be deployed without any warning. The security could be improved by blocking the deployment until the operator securely configure the CORS setting. Note that it's currently insecure by default so adding a block will impact compatibility.

Part of the SSO, we would like to support permissions management via third parties such as Active Directory, LDAP, JumpCloud, etc. It includes fields synchronization and roles mapping.

Hi Strapi team, A recurring concern for teams running Strapi as a public-facing backend — form submissions, user-contributed media, community platforms — is that the Upload plugin accepts files with no content inspection. Today this has to be solved out of band, usually with a separate scanner watching the upload folder or the S3 bucket, which creates a window where malicious files are reachable via the Media Library before detection. Would there be interest in either (a) a documented extension point in the Upload plugin for pre-save validation of file bytes, or (b) a first-party "antivirus" plugin that runs ClamAV (local or remote clamd) before the file is persisted? The ergonomic API would be a beforeUpload / afterUpload lifecycle that can reject a file before it reaches the provider, with a typed verdict (clean / malicious / scan_error) so that timeouts and scanner failures don't silently fall through as "clean". In the Node.js ecosystem, the two practical ClamAV wrappers are clamscan and pompelmi. Happy to prototype a plugin if there's interest. Disclosure: I maintain pompelmi ( https://github.com/pompelmi/pompelmi ). This is not a pitch for pompelmi specifically — the underlying gap is Strapi-side and any scanner works.

The new SSO feature of Strapi is great and it has it's pros - however, also cons. And the biggest con is that it's possible for intruder to access another user's account by creating an account on some provider with an e-mail of such admin user. For example, let's say you have two provider: Google and Sign in with Apple. An admin panel user has an Apple ID, but doesn't have a Google account. An intruder wants to access the system and knows an email of the user. He creates a Google account with an e-mail address of a user. Then he logs in to the admin panel without any problems under that user's account and gains access to the data in Strapi. See: https://github.com/strapi/strapi/issues/9466

When integrating with oauth2, I think it's more common to use strapi as resource server instead of client(strapi is headless). It's the duty of frontend (like nextjs) to get user authenticated and obtain the access token which used in Authentication header when access strapi, what strapi should do is validate access token and get user info from it. This make strapi more easy to integrate with other backend. see: https://github.com/strapi/strapi/issues/12207

Currently any admin user with edit rights can edit any other admin user (including themselves) to elevate their permissions beyond their current role. Related EE TID: 8077