feat: Replace CryptoJS with Web Crypto

[dplewis]

Pull Request

• Report security issues confidentially.
• Any contribution is under this license.
• Link this pull request to an issue.

Issue

Active development of CryptoJS has been discontinued. Nowadays, NodeJS and modern browsers have a native crypto module. This allows the SDK to have isomorphic encryption.

Closes: #2494

Approach

• Replace Crypto-JS ASE-CBC with Web Crypto ASE-GCM-256 due to passphases key diveration being incompatible (could change in the future) and GCM is more secure Potential breaking change
• Remove Parse.enableEncryptedUser(), Parse.encryptedUser, Parse.isEncryptedUser as they are not needed Breaking Change
• Remove default support for React-Native, developers will now have to polyfill webcrypto Breaking Change
• CryptoJS is syncronous while Web Crypto is asyncronous meaning some functions won't be available when this feature is turned on, like when using AsyncStorage. Breaking Change
  • Parse.User.current
  • Parse.User.isCurrent
• Update Readme with instructions to create a custom crypto controller
• Remove dependency on crypto-js and react-native-crypto-js

Due to the encryption and decryption method being different, developers who used this feature before won't be able to decrypt users that are already logged in but not cached on disk. I'm not sure how many developers were using this feature as it was undocumented. There are two ways for devs to solve this.

1. Forcefully logging out users (deleting sessions). This will clean up the local storage.
2. Follow the readme instructions and use the old crypto-js CryptoController as your custom controller. This will require the developers to install those packages.

Tasks

• Add tests
• Add changes to documentation (guides, repository pages, code comments)

[parse-github-assistant]

🚀 Thanks for opening this pull request!

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 100.00%. Comparing base (566cfaa) to head (d8c9f55).

Additional details and impacted files

@@            Coverage Diff            @@
##             alpha     #2501   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           64        64           
  Lines         6244      6264   +20     
  Branches      1452      1453    +1     
=========================================
+ Hits          6244      6264   +20     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[dplewis]

@mtrezza Do you want to plan a Version 7.0.0 release?

[mtrezza]

The thing is that we wouldn't be able to upgrade the JS SDK in Parse Server until December 2025 if we merged this. So we can't really merge this so easily with our current branch setup. We could tag this PR for merge on next major release.

[dplewis]

What does the server have to do with this?

[mtrezza]

The Parse JS SDK is a dependency of Parse Sever.

[dplewis]

The server has a lot of dependencies, because the SDK breaks doesn’t mean the server breaks.

In the case of this PR. You can’t log in on the server, there is no local storage like the browser, there is nothing to encrypt, so this doesn’t break the server.

[mtrezza]

The difference is that the Parse JS SDK is a fully exposed API in Cloud Code, not merely a "hidden" dependency (which we want to change). The "hidden" dependencies are tested indirectly through the Parse Server API tests. The fully exposed JS SDK API may not be completely tested in Parse Server because not all of its APIs apply there, as you mentioned. Because of that risk, major version increments in tandem are safer. If we decide to go ahead and merge a major version upgrade of the JS SDK, we'd need to make sure that even ineffective APIs of the JS SDK do not break anything, for example methods that wouldn't make sense to be called in Cloud Code, but fail gracefully or have no effect at all. I agree that we could do the upgrade, but it requires some extra care. And it would need to be a dedicated major release, meaning we cannot combine it with other breaking changes, as we usually would do to minimize the number of major releases. Are there any other PRs that should go into a 7.0.0 release?

[dplewis]

For version 7.0.0

• Replace CryptoJS with Web Crypto feat: Replace CryptoJS with Web Crypto #2501
• Replace XMLHttpRequest with Fetch feat: Replace XMLHttpRequest with Fetch API #2503
• Convert the project to a ES Module which would require us moving from browserify feat: Add vite #2425

[mtrezza]

Which one of these are breaking and are there interdependencies? If only this crypto PR is breaking, then we can do a 7.0.0 release without waiting for the other ones. Since this is a "special" major release, it would make it also easier to control.