nopp - npm Package Compare versions

Comparing version 1.0.1 to 1.0.2

package.json

		{
		"name": "nopp",
		"version": "1.0.1",
		"description": "NoPP (No Prototype Pollution) – tiny helper to protect against Prototype Pollution vulnerabilities in your application regardless if they introduced in your own code or in 3rd-party code.",
		"version": "1.0.2",
		"description": "NoPP (No Prototype Pollution) – tiny helper to protect against Prototype Pollution vulnerabilities in your application",
		"main": "index.js",
		@@ -6,0 +6,0 @@ "scripts": {

README.md

		# nopp

		`NoPP` (No Prototype Pollution) – tiny helper to protect against Prototype
		Pollution vulnerabilities in your application regardless if they introduced in
		your own code or in 3rd-party code.
		Pollution vulnerabilities in your application, regardless if they introduced in
		your own code or by 3rd-party code.

		@@ -14,3 +14,3 @@ ## How this package works?

		We believe there is a legitimate cases of prototypes change, but they should
		We believe that there are legitimate cases of prototype changes, but they should
		happen only during the initialization step. Hence, we recommend including
		@@ -26,3 +26,3 @@ this package as the last one in your application code.
		package will protect you even in case you're using a package that contains
		a Prototype Pollution vulnerability
		a Prototype Pollution vulnerability.

		@@ -58,4 +58,2 @@ ## What type of applications should use this package?



		## Example
		@@ -78,3 +76,3 @@

		In some rare cases attempts to exploit the Prototype Pollution vulnerability
		In some rare cases, attempts to exploit the Prototype Pollution vulnerability
		can cause `TypeError: Cannot redefine property` or
		@@ -84,1 +82,23 @@ `TypeError: Cannot assign to read only property` exception and cause DoS
		implemented.

		## FAQ

		### Should I prefer `nopp` instead of the `--frozen-intrinsics` Node.js flag?

		[`--frozen-intrinsics`](https://nodejs.org/docs/latest-v17.x/api/cli.html#--frozen-intrinsics) added in Node.js v11.12.0 and currently has experimental stability level.

		The main purpose of the flag is exactly the same as of this package – to protect runtime from unintended modifications of prototypes.

		We believe there are numerous reasons why you may prefer using `nopp`:

		1. You control when to import the package hence when to freeze prototypes. In many cases application actually modify prototypes a bit to add some tweaks or polyfills. In such cases usage of `--frozen-intrinsics` will be not possible without significant application code refactoring. Unlike `nopp` which should be imported after all other packages and in most of the cases cause no backward compatibility issues.
		2. `nopp` is also applicable for client-side applications. You may prefer to use it for consistency between backend Node.js code and client-side application code.
		3. If you are a [Snyk user](https://snyk.io), we are able to detect the usage of the `nopp` package as part of your application and ignore prototype pollution vulnerabilities in your application code automatically, and help reduce the noise level of your overall security alerts.

		### Is the `--disable-proto` Node.js flag enough to be protected?

		No.

		[`--disable-proto`](https://nodejs.org/docs/latest-v17.x/api/cli.html#--disable-protomode) added in Node.js v12.17.0. It is able to delete `__proto__` property from the runtime completely and prevent some prototype pollution attack payloads.

		Unfortunately, unlike `nopp`, it doesn't protect your application against `constructor.prototype` type of payloads.

nopp - npm Package Compare versions

New alerts

Fixed alerts

Improved metrics