+```
+### The question is, where's the problem?
+We need to see the whole story here!
+Why is buffer class exists in NodeJS API?
+Client-side JavaScript spares us the need to deal with memory allocation.
+Like many of its peer languages, in JS the underlying engine (e.g V8) allocates memory and garbage-collect it as needed, making coding simpler and safer.
+In the browser, preventing access to memory is also necessary to maintain the sandbox JS runs in.
+When JS expanded to the server with Node, the browser sandbox was removed, and the need for easy and fast binary data processing increased.
+To address these needs, Node introduced the Buffer class, which deals with binary data.
+Client-side JavaScript spares us the need to deal with memory allocation.
+Like many of its peer languages, in JS the underlying engine (e.g. V8) allocates memory and garbage-collects it as needed, making coding simpler and safer.
+In the browser, preventing access to memory is also necessary to maintain the sandbox JS runs in.
+When JS expanded to the server with Node, the browser sandbox was removed, and the need for easy and fast binary data processing increased.
+To address these needs, Node introduced the Buffer class, which deals with binary data.
+
+In versions of Node.js prior to 6.0.0, Buffer instances were created using the Buffer constructor function, which allocates the returned Buffer differently based on what arguments are provided:
+
+* Passing a number as the first argument to Buffer() (e.g. new Buffer(10)) allocates a new Buffer object of the specified size. Prior to Node.js 8.0.0, the memory allocated for such Buffer instances is not initialized and can contain sensitive data. Such Buffer instances must be subsequently initialized by using either buf.fill(0) or by writing to the entire Buffer. While this behavior is intentional to improve performance, development experience has demonstrated that a more explicit distinction is required between creating a fast-but-uninitialized Buffer versus creating a slower-but-safer Buffer. Since Node.js 8.0.0, Buffer(num) and new Buffer(num) return a Buffer with initialized memory.
+
+* Passing a string, array, or Buffer as the first argument copies the passed object's data into the Buffer.
+
+* Passing an ArrayBuffer or a SharedArrayBuffer returns a Buffer that shares allocated memory with the given array buffer.
+
+Because the behavior of new Buffer() is different depending on the type of the first argument, security and reliability issues can be inadvertently introduced into applications when argument validation or Buffer initialization is not performed.
+
+For example, if an attacker can cause an application to receive a number where a string is expected, the application may call new Buffer(100) instead of new Buffer("100"), it will allocate a 100 byte buffer instead of allocating a 3 byte buffer with content "100".
+This is commonly possible using JSON API calls.
+Since JSON distinguishes between numeric and string types, it allows injection of numbers where a naive application might expect to always receive a string.
+Before Node.js 8.0.0, the 100 byte buffer might contain arbitrary pre-existing in-memory data, so may be used to expose in-memory secrets to a remote attacker.
+Since Node.js 8.0.0, exposure of memory cannot occur because the data is zero-filled.
+However, other attacks are still possible, such as causing very large buffers to be allocated by the server, leading to performance degradation or crashing on memory exhaustion.
+
+To make the creation of Buffer instances more reliable and less error-prone, the various forms of the new Buffer() constructor have been deprecated and replaced by separate Buffer.from(), Buffer.alloc(), and Buffer.allocUnsafe() methods.
+
+* Buffer.alloc(size[, fill[, encoding]]) returns a new initialized Buffer of the specified size. This method is slower than Buffer.allocUnsafe(size) but guarantees that newly created Buffer instances never contain old data that is potentially sensitive. A TypeError will be thrown if size is not a number.
+
+* Buffer.allocUnsafe(size) and Buffer.allocUnsafeSlow(size) each return a new uninitialized Buffer of the specified size. Because the Buffer is uninitialized, the allocated segment of memory might contain old data that is potentially sensitive.
+
+### What makes Buffer.allocUnsafe() "unsafe"?
+When calling Buffer.allocUnsafe(), the segment of allocated memory is uninitialized (it is not zeroed-out).
+While this design makes the allocation of memory quite fast, the allocated segment of memory might contain old data that is potentially sensitive.
+Using a Buffer created by Buffer.allocUnsafe() without completely overwriting the memory can allow this old data to be leaked when the Buffer memory is read
+
+### Where's the problem if I can always use Buffer.alloc() instead of Buffer.allocUnsafe() ?
+Allocation is a synchronous operation and we know that single threaded Node.js doesn't really feel good about synchronous stuff.
+Unsafe allocation is much faster than safe because the buffer sanitization step takes time.
+Safe allocation is, well, safe, but there is a performance trade-off.
+
+
+## Further Reading
+
+[link 1](https://snyk.io/vuln/npm:ws:20160104)
+[link 2](https://snyk.io/blog/exploiting-buffer/)
+
diff --git a/docs/description/security-node_detect-child-process.md b/docs/description/security-node_detect-child-process.md
new file mode 100644
index 000000000..45accde0a
--- /dev/null
+++ b/docs/description/security-node_detect-child-process.md
@@ -0,0 +1,115 @@
+# Command Injection in Node.js
+
+Before we dive into the rule details, we have to clarify **command Injection**
+
+An injection vulnerability manifests when application code sends untrusted user input to an interpreter as part of a command or query!
+### What an attacker can do
+Using command injection, an attacker can execute arbitrary commands on the host operating system of a vulnerable application.
+This flaw gives enormous opportunities to an attacker, ranging from reading restricted file contents to installing malware with which the attacker can take full control of the server and hot network!
+
+### Demonstration of an attack
+Before we demonstrate how an attacker can cause serious damage to our application, let's see how **child_process** works!
+The child_process core module enables Node developers to invoke underlying OS commands from the application code.
+Due to its name and simplicity of use,the child_process.exec method is commonly used for making system calls.
+The exec method takes three arguments: a command in string format,an optional options object, and a callback function,as demonstrated below
+```javascript
+child_process.exec(command[,options][, callback])
+```
+**So where's the problem?** Although the exec method executes OS commands in a nonblocking manner, perfectly aligning with Node's async programming paradigm, its flexibility to pass the command as a string often invites **injection flaws**.
+This is particularly the case when a **user input** is used to construct the command.
+For example, the following example shows using the ``` child_process.exec ``` method to invoke the **gzip** command that appends a user-supplied dynamic file path to construct the gzip command.
+
+```javascript
+child_process.exec(
+ 'gzip' + req.body.file_path,
+ function (err, data) {
+ console.log(data);
+ });
+```
+To exploit the injection vulnerability in the preceding code, an attacker can append **; rm -rf /**, for instance, to the file_path input.
+This allows an attacker to break out of the gzip command context and execute malicious commands that delete all files on the server.
+As part of the user input, an attacker also chain multiple commands by using characters such as **;,&,|,||,$(),<,>, and >>**.
+The attack manifests because, under the hood, the exec method spawns a new bin/sh process and passes the command argument for execution to this system shell.
+This is equivalent to opening a Bash interpreter for an attacker to run any commands with the same privileges as the vulnerable application!
+
+### Preventing Command Injection
+Now that you know the potential of an injection attack to cause severe damage, let's go over methods to prevent it.
+
+### Do not use exec with String concatenation
+As you saw in the example above, exec spawns a new shell, so if the **command** argument is a user input (string concatenation may denote user input), that may cause serious damage.
+
+### Use execFile OR spawn instead of exec
+When possible, use the child_process module's **execFile** or **spawn** methods instead of exec.
+Unlike exec, the spawn and execFile method signatures force developers to separate the command and its arguments.
+Check the example below,
+
+```javascript
+var file_path = req.body.file_path;
+
+//Execute gzip command
+child_process.execFile(
+ 'gzip',
+ [file_path],
+ function (err,data) {
+ console.log(data);
+ });
+```
+Any malicious commands chained to file_path user input end up in execFile method's second argument of type array.
+Any malicious commands in user input are simply ignored or cause a syntax error if they are not relevant to the target command, thus failing the command injection attempts!
+
+### Do not use execFile or spawn with option:true
+let's dive into **spawn and execFile** methods!
+```javscript
+child_process.spawn(command[,args][,options])
+child_process.execFile(file[,args][,options][,callback])
+```
+
+They both have several options that a user can manipulate.
+One of them is the option **shell:true**.
+If the shell option is true, then the command runs into a new shell and becomes as dangerous as exec method can be.
+
+### Input Validation
+Although execFile or spawn are safer alternatives to exec, these methods cannot completely prevent command injection.
+The related scenarios include developers using these methods to invoke a custom script that processes user input or to execute OS commands (such as find, awk, or sed) that allow passing options to enable file read/write.
+Just like other injection attacks, command injection is primarily possible due to insufficient input validation.
+To protect against it, verify that user-controlled command arguments and command options are valid.
+
+### Using a Whitelist approach for input Validation
+When writing the validation logic, use a whitelist approach; that is, define what is permitted and reject any input that doesn't fit this definition.
+Avoid writing this logic in an opposite manner(blacklist approach), or, in other words, by comparing input against a set of known unsafe characters.
+Attackers can often find a way to circumvent such filters by being creative with input construction!
+
+## Rule Details
+
+Examples of **incorrect** code for this rule:
+
+```javascript
+//exec invalid
+var path = "user input";
+child_process.exec("ls -l" + path, function (err, data) {});
+
+//execFile invalid
+child_process.execFile("node",["--version"],{shell:true},function(error,stdout,stderr){if(error){throw error}});
+
+//invalid spawn
+child_process.spawn("ls-la",["--version"],{shell:true});
+
+```
+
+Examples of **correct** code for this rule:
+
+```javascript
+//exec valid
+child_process.exec("ls", function (err, data) {});
+
+//execFile valid
+child_process.execFile("node",["--version"],{cwd:"..."},function(error,stdout,stderr){if(error){throw error}});
+
+//spawn valid
+child_process.spawn("ls-la",["--version"],{cwd:"..."})
+```
+
+### Further Reading
+[link 1](https://www.oreilly.com/library/view/securing-node-applications/9781491982426)
+[link 2](https://hackernoon.com/nodejs-security-issue-javascript-node-example-tutorial-vulnerabilities-hack-line-url-command-injection-412011924d1b)
+
diff --git a/docs/description/security-node_detect-crlf.md b/docs/description/security-node_detect-crlf.md
new file mode 100644
index 000000000..be7dc5003
--- /dev/null
+++ b/docs/description/security-node_detect-crlf.md
@@ -0,0 +1,59 @@
+# detect log forging attack (detect-crlf)
+So what about **CRLF** (Carriage Return Line Feed) aka log injection?
+Applications typically use log files to store a history of events or transactions for later review, statistics gathering or debugging.
+Depending on the nature of the application, the task of reviewing log files may be performed manually on an as-needed basis or automated with a tool that automatically culls logs for important events or trending information.
+
+Writing unvalidated user input to log files can allow an attacker to forge log entries or inject malicious content into the logs. This is called log injection.
+
+Log injection vulnerabilities occur when:
+
+* Data enters an application from an untrusted source.
+
+* The data is written to an application or system log file.
+
+Successful log injection attacks can cause:
+
+* Injection of new/bogus log events (log forging via log injection)
+
+* Injection of XSS attacks, hoping that the malicious log event is viewed in a vulnerable web application
+
+But le's see some action!
+
+### Attack Mechanics
+An attacker may craft a malicious request that may deliberately fail, which the application will log, and when the attacker's user input is unsanitized, the payload is sent as-is to the logging facility.
+Vulnerabilities may vary depending on the logging facility:
+
+* Log Forging (CRLF)
+Let's consider an example where an application logs a failed attempt to login to the system.
+A vary common example for this is as follows:
+
+```javascript
+var userName = ewq.body.userName;
+console.log('Error: attempt to login with invalid user:', userName);
+```
+When user input is sanitized and the output mechanism is an ordinary terminal sdtout facility then the application will be vulnerable to CRLF injection, where an attacker can create a malicious payload as follows:
+
+```javascript
+curl http://localhost:4000/login -X POST --data 'userName=vyva%0aError: alex moldovan failed $1,000,000 transaction&password=Admin_123&_csrf='
+```
+Where the **userName** parameter is encoding in the request the LF symbol which will result in a new line to begin.
+Resulting log output will look as follows:
+```javascript
+Error:attempt to login with invalid user: vyva
+Error:alex moldovan failed $1,000,000 transaction
+```
+
+### Log injection Escalation
+An attacker may craft malicious input in hope of an escalated attack where the target isn't the logs themselves, but rather the actual logging system.
+For example, if an application has a back-office web app that manages viewing and tracking the logs, then an attacker may send an XSS payload into the log, which may not result in log forging on the log itself, but when viewed by a system administrator on the log viewing web app then it may compromise it and result in XSS injection that if the logs app is vulnerable!
+
+### How DO I Prevent it?
+As always when dealing with user input:
+* Do not allow user input into logs
+* Encode to proper context,or sanitize user input
+
+
+## Further Reading
+
+[link 1](http://nodegoat.herokuapp.com/tutorial/a1)
+[link 2](https://www.owasp.org/index.php/Log_Injection)
diff --git a/docs/description/security-node_detect-dangerous-redirects.md b/docs/description/security-node_detect-dangerous-redirects.md
new file mode 100644
index 000000000..ca26c39ec
--- /dev/null
+++ b/docs/description/security-node_detect-dangerous-redirects.md
@@ -0,0 +1,70 @@
+# detect dangerous redirects
+
+### What are Unsafe Redirects?
+Unsafe or unvalidated redirects are important security considerations for any web developer!
+Express provides native support for redirects, making them easy to implement and use.
+However, Express leaves the task of performing input validation to the developer.
+
+Here's the definition according to OWASP.org's "Unvalidated Redirects and Forwards" cheat sheet:
+
+* Unvalidated redirects and forwards are possible when a web application accepts untrusted input that could cause the web application to redirect the request to a URL contained within untrusted input.
+
+Redirects are commonly used in login and authentication processes, so users can be redirected back to the page they were on before logging in.
+Other scenarios exist but vary based on business need or application type.
+
+### Why are they bad?
+Redirects that do not validate user input can enable attackers to launch phishing scams, steal user credentials, and perform other malicious actions.
+
+If an attacker discovers that you are not validating external, user-supplied input, they may exploit this vulnerability by posting specially-crafted links on forums, social media, and other public places to get users to click it.
+
+At face value, these URLs may look legitimate to the user - since all of them will contain your organization's hostname
+
+* https://example.com/login?url=http://examp1e.com/bad/things
+
+However, if the server-side redirect logic does not validate data entering the url parameter, your users may end up on a site that looks exactly like yours (examp1e.com), but ultimately serves the needs of criminal hackers!
+
+This is just one example of how attackers can take advantage of unsafe redirect logic.
+
+### An Example of an Unsafe Redirect
+In the following code, you'll see that /login accepts unvalidated data from the url parameter and passes it directly into the Express res.redirect() method.
+As a result, Express will redirect the user to whatever URL is entered or supplied so long as the user is authenticated.
+
+```javascript
+var express = require('express');
+var port = process.env.PORT || 3000;
+var app = express();
+
+app.get('/login', function (req, res, next) {
+
+ if(req.session.isAuthenticated()) {
+
+ res.redirect(req.query.url);
+ }
+});
+
+app.get('/account', function (req, res, next) {
+ res.send('Account page');
+});
+
+app.get('/profile', function (req, res, next) {
+ res.send('Profile page');
+});
+
+app.listen(port, function() {
+ console.log('Server listening on port ' + port);
+});
+```
+
+### How to prevent it?
+
+* Simply avoid using redirects and forwards.
+
+* If used, don’t involve user parameters in calculating the destination. This can usually be done.
+
+* If destination parameters can’t be avoided, ensure that the supplied value is valid, and authorized for the user.
+It is recommended that any such destination parameters be a mapping value, rather than the actual URL or portion of the URL and that server-side code translates this mapping to the target URL.
+
+
+## Further Reading
+[link 1](http://nodegoat.herokuapp.com/tutorial/a10)
+[link 2](https://blog.hailstone.io/how-to-prevent-unsafe-redirects-in-node-js/)
diff --git a/docs/description/security-node_detect-eval-with-expr.md b/docs/description/security-node_detect-eval-with-expr.md
new file mode 100644
index 000000000..83a407263
--- /dev/null
+++ b/docs/description/security-node_detect-eval-with-expr.md
@@ -0,0 +1,53 @@
+# detect eval with string concatenation (detect-eval-with-expr)
+### Is eval() Evil?
+JavaScript is an interpreted language, and like so many of its peers, it includes the powerful eval() function.
+eval() takes a string and executes it as if it was regular JavaScript code.
+It's incredibly powerful and incredibly easy to abuse in ways that make your code slower and harder to maintain.as a general rule, if you're using eval() there's probably something wrong with your design.
+
+### Common mistakes
+Here's the classic misuse of eval().
+You have a JavaScript object `foo` and you want to access a property on it-but you don't know the name of the property until runtime.
+Here's how **NOT** to do it:
+
+```javascript
+var property = 'bar';
+var value = eval('foo.' + property);
+```
+Yes, it will work, but every time that piece of code runs JavaScript will have to kick back into interpreter mode, showing down your app.
+It's also dirt ugly.
+
+Here's the right way of doing above:
+```javascript
+var property = 'bar';
+var value = foo[property];
+```
+In JavaScript, square brackets act as an alternative to lookups using a dot.
+The only difference is that square bracket syntax expects a string.
+
+### Security Issues
+In any programming language you should be extremely cautious of executing code from untrusting source.
+The same is true for JavaScript - you should be extremely cautious of running eval() against any code that might have been tampered with - for example, strings taken from the page query string.
+Executing untrusted code can leave you vulnerable to XSS (cross-site-scripting) attacks.
+
+Here's a list of applications in which you must use eval():
+* Running code remotely sent from a server
+* Evaluating user input code**
+* Running dynamically generated code
+* Running a script and storing its result
+
+**While applications 1,3 and 4 are generally safe, there re real security concerns to our second application - evaluating user input code!
+
+Using eval() does not automatically open you up to an XSS attack nor does it mean there is some lingering security vulnerability that you’re not aware of.
+Just like any tool, you need to know how to wield it correctly, but even if you use it incorrectly, the potential for damage is still fairly low and contained.
+
+### When eval() is unavoidable ?
+Let's say you have some raw text, and some of that text is JS, you could use eval() to turn the quoted JavaScript back into JavaScript and execute it.
+When that is the task you need to do, eval() is the only thing that will work, but it's very rare that you're needing to execute quoted JavaScript code from another language (and this should be done with caution when you do).
+
+### Conclusion
+Eval Should never be used when any of the input is out of control!
+
+## Further Reading
+[link 1](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/eval)
+[link 2](https://blog.risingstack.com/node-js-security-tips/)
+[link 3](https://24ways.org/2005/dont-be-eval)
diff --git a/docs/description/security-node_detect-html-injection.md b/docs/description/security-node_detect-html-injection.md
new file mode 100644
index 000000000..2c02d18ce
--- /dev/null
+++ b/docs/description/security-node_detect-html-injection.md
@@ -0,0 +1,149 @@
+# Detect html injection (detect-html-injection)
+### Introduction to HTML Manipulation Function
+When a method or operation allows HTML manipulation if it is possible to control, even partially, an argument, then it is possible to manipulate, to some extent the HTML and consequently gain control of the user interface or execute JavaScript using classic Cross Site Scripting attacks.
+
+Data flow starts from Sources(input data that could be tainted) and ends to Sinks (functions potentially dangerous).
+
+In software security the **Sources[*]** are to be considered starting points where untrusted input data is taken by an application.
+
+There are two types of input sources
+* Direct
+* Indirect
+
+So we will analyze the various types of Direct/Indirect input and how malicious JavaScript code can cause damage by exploiting incorrect programming techniques.
+
+In software security the **Sinks[*]** are meant to be the points in the flow where data depending from sources is used in a potentially dangerous way resulting in loss of Confidentiality, Integrity or Availability.
+
+This means that a function is a Sink if its behavior is generally safe but would be dangerous with a tainted input data.
+
+To understand the difference between Source and tainted Source take a look to the following code:
+```javascript
+
+```
+**Source**: document.URL
+
+**Sink**: document.write()
+
+**Result**: document.write("");
+
+The exploit will take place when visiting the following URL:
+
+ http://example.tld/page.html#name=
+
+* Glossary:
+Sources: Sources are all the DOM Properties that can be influenced by an attacker.
+Sinks: Sinks are all the DOM Properties, JavaScript functions, and other Client-side entities that can lead to or influence Client-side code execution.
+
+###Table of dangerous JavaScript functions/properties for HTML manipulation
+ Here below we report a table with the principal sinks that allow HTML manipulation which likely will result in JavaScript execution.
+
+Function Name | Browser | Example
+------------- | ------- | -------
+document.write | All | document.write(“” + userControlledVal + “”);
+document.writeln | All | document.writeln("" + userControlledVal + "");
+anyElement.innerHTML | All | divElem.innerHTML = “Hello ” + userControlledVal
+anyElement.outerHTML | All | divElem.outerHTML = "Hello " + userControlledVal
++ "
"
+anyElement.insertAdjacentHTML | All | divElem.insertAdjacentHTML("",""+ userControlledVal + "");)
+
+### Difference between document.write functions and properties like innerHTML
+The document.write method:
+
+Let's take functions like document.write (or document.writeln) as an example to explain better the Sink and let's see the difference between this function and for example, the property innerHTML.
+
+As we can see, the document.write goes to operate in a direct way as Sink writing (output) the malicious code entered by a user who checks the value, going, in fact, to the following URL:
+
+ http://example.tld/page.html#?foo=
+
+ And, by analyzing the page code:
+
+```javascript
+
+```
+We can see that the Sink in question, therefore, the document.write will have the task of printing screen the data value inserted into the function as an argument, and though having passed the user argument of malicious JavaScript code, then the function will only unintentionally execute writing in the DOM code in question, then:
+
+```javascript
+alert(document.cookie);
+```
+
+Building up the browser side, then Client-side, a popup containing the cookie values of the current user session.
+
+**The innerHTML method:**
+Concerning the use of the innerHTML method, and, of how this can be abused by an object controlled directly by a user, we can make a more detailed example, then let’s take the following code:
+```javascript
+John Doe
+
+```
+As you can see, if we call the innerHTML method to retrieve the information, nothing happens, even in the case that instead of the name "John Doe" there has been the malicious JavaScript code; Instead let’s take another example:
+```javascript
+John Doe
+
+```
+
+Following this example script and browsing its URL:
+
+ http://example.tld/page.html?name=
+
+In this case, the browser will return us a window that is to show us that our JavaScript code passed to the URL parameter name, was executed.
+
+### Examples of vulnerable source code for the HTML Manipulation vulnerabilities
+At this point we can do is give a few examples so you can see the various existing possibilities that allow you to identify and subsequently Exploiting a vulnerability in HTML Manipulation type, then:
+* DOM Based XSS
+* Stored DOM Based XSS
+* Others
+
+###DOM Based Cross-Site-Scripting(DOM XSS)
+So,to explain this type of vulnerabality,we can also take one of the above examples that made it very simple:
+Taking the following vulnerable code:
+```javascript
+
+```
+* Source: document.URL
+* Sink: document.write()
+* Result: document.write(“”);
+
+The attack is possible to a Client-side level (this due to the # fragment identifier).
+
+To exploiting this attack just go to the following URL and specify the malicious code in the “foo=” parameter:
+
+ http://example.tld/page.html#foo=
+
+## Rule Details
+
+This rule aims to...
+
+Examples of **incorrect** code for this rule:
+
+```js
+
+// fill me in
+
+```
+
+Examples of **correct** code for this rule:
+
+```js
+
+// fill me in
+
+```
+
+## Further Reading
+[link 1](http://blog.blueclosure.com/2017/09/javascript-dangerous-functions-part-1.html)
diff --git a/docs/description/security-node_detect-improper-exception-handling.md b/docs/description/security-node_detect-improper-exception-handling.md
new file mode 100644
index 000000000..63de84a4c
--- /dev/null
+++ b/docs/description/security-node_detect-improper-exception-handling.md
@@ -0,0 +1,20 @@
+# detect improper exception handling (detect-improper-exception-handling)
+
+Node.js has the process global object, which is an EventEmitter object that in this case emits uncaught exceptions and brought up to the main event loop. In the event that an uncaught exception is thrown while your application is executing, it will result to it crashing. Thus, it is essential to make a listener for uncaught exceptions uwing the process object. There is no need for importing the process core module as it is nautomatically injected with Node.js.
+
+It is worth noting that this way of exception handling is intended as a last resort. Moreover, this type of event signals that the application is in an undefined state, and resuming the application is strongly discouraged and can cause greater issues.
+
+To not miss any uncaught exception and correctly use it is to do synchronous cleanup of allocated resources such as using handlers, file descriptors, custom loggers and similar before exiting the process with a non-zero exit code. Be aware that in displaying error messages it is recommended to log the necessary details but not as far as leaking detailed information such as stack traces to the user.
+
+### Example
+```javascript
+process.on("uncaughtException", function(err) {
+ // clean up allocated resources
+ // log necessary error details to log files
+ process.exit(1); // exit the process to avoid unknown state
+});
+```
+
+[link 1](https://cheatsheetseries.owasp.org/cheatsheets/Nodejs_Security_Cheat_Sheet.html#handle-uncaughtexception)
+[link 2](https://nodejs.org/dist/latest-v16.x/docs/api/process.html#event-uncaughtexception)
+[link 3](https://nodejs.dev/learn/error-handling-in-nodejs#catching-uncaught-exceptions)
\ No newline at end of file
diff --git a/docs/description/security-node_detect-insecure-randomness.md b/docs/description/security-node_detect-insecure-randomness.md
new file mode 100644
index 000000000..255e790f5
--- /dev/null
+++ b/docs/description/security-node_detect-insecure-randomness.md
@@ -0,0 +1,71 @@
+# detect insecure randomness via Math.random() (detect-insecure-randomness)
+### Insecure Randomness
+The **Math.random()** function returns a floating-point, pseudo-random number in the range 0–1 (inclusive of 0, but not 1) with approximately uniform distribution over that range — which you can then scale to your desired range.
+The implementation selects the initial seed to the random number generation algorithm; it cannot be chosen or reset by the user.
+
+The **Math.random()** is often used to generate nonpredictable values such as random tokens, resource IDs, or UUIDs.
+However, Math.random() is cryptographically insecure.
+It can produce predictable values and is therefore not safe to use in a security-sensitive context.
+
+### How To Prevent It?
+Math.random() does not provide cryptographically secure random numbers.
+Do not use them for anything related to security. Use the Web Crypto API instead, and more precisely the window.crypto.getRandomValues() method.
+
+### Crypto.getRandomValues()
+The Crypto.getRandomValues() method lets you get cryptographically strong random values.
+The array given as the parameter is filled with random numbers (random in its cryptographic meaning).
+
+To guarantee enough performance, implementations are not using a truly random number generator, but they are using a pseudo-random number generator seeded with a value with enough entropy.
+The PRNG used differs from one implementation to the other but is suitable for cryptographic usages.
+Implementations are also required to use a seed with enough entropy, like a system-level entropy source.
+
+### Syntax
+```javascript
+cryptoObj.getRandomValues(typedArray);
+```
+### Examples
+```javascript
+/* Assuming that window.crypto.getRandomValues is available */
+
+var array = new Uint32Array(10);
+window.crypto.getRandomValues(array);
+
+console.log("Your lucky numbers:");
+for (var i = 0; i < array.length; i++) {
+ console.log(array[i]);
+}
+```
+For a more secure implementation of **Math.random()**, you could try this:
+
+```javascript
+function secureMathRandom() {
+ // Divide a random UInt32 by the maximum value (2^32 -1) to get a result between 0 and 1
+ return window.crypto.getRandomValues(new Uint32Array(1))[0] / 4294967295;
+}
+```
+
+
+## Rule Details
+
+This rule aims to...
+
+Examples of **incorrect** code for this rule:
+
+```js
+
+// fill me in
+
+```
+
+Examples of **correct** code for this rule:
+
+```js
+
+// fill me in
+
+```
+
+
+## Further Reading
+[link 1](https://developer.mozilla.org/en-US/docs/Web/API/Crypto/getRandomValues)
+[link 2](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Math/random)
\ No newline at end of file
diff --git a/docs/description/security-node_detect-non-literal-require-calls.md b/docs/description/security-node_detect-non-literal-require-calls.md
new file mode 100644
index 000000000..8ac0e1a54
--- /dev/null
+++ b/docs/description/security-node_detect-non-literal-require-calls.md
@@ -0,0 +1,23 @@
+# Non literal require calls may cause an attack (detect-non-literal-require-calls)
+### require() with only literal arguments!
+Avoid requiring/importing another file with a path that was given as a parameter due to the concern that it could have originated from user input.
+This rule can be extended for accessing files in general(i.e fs.readFile()) or other sensitive resource access with dynamic variables originating from user input!
+Malicious user input could find its way to a parameter that is used to require tampered files, for example, a previously uploaded file on the filesystem, or access already existing system files.
+
+
+## Rule Details
+This rule is looking for require() with non-literal arguments!
+
+Examples of **incorrect** code for this rule:
+
+```js
+// insecure, as helperPath variable may have been modified by user input
+const uploadHelpers = require(helperPath);
+```
+
+Examples of **correct** code for this rule:
+
+```js
+// secure
+const uploadHelpers = require('./helpers/upload');
+```
diff --git a/docs/description/security-node_detect-nosql-injection.md b/docs/description/security-node_detect-nosql-injection.md
new file mode 100644
index 000000000..7ac2f09c6
--- /dev/null
+++ b/docs/description/security-node_detect-nosql-injection.md
@@ -0,0 +1,88 @@
+# detect NOsql injection (detect-nosql-injection)
+### The $where operator attack
+The **$where** operator has a vary dangerous feature: it allows you to pass a string that will be evaluated inside your server.
+
+To reproduce the problem, suppose that you have an online store and want to find out which users have more than X canceled orders.
+You could query as the following:
+```javascript
+var query = {
+ $where: "this.canceledOrders > " + req.body.canceled
+}
+db.collection('users').find(query).each(function(err, doc){
+ console.log(doc);
+})
+```
+
+In this case,mongo-sanitize will not help you if the input string **'0; return true'**.
+Your $where clause will be evaluated aas **this.canceledOrders > 0; return true** and all users would be returned.
+
+Or you could receive **'0; while(true){}'** as input and suffer a DoS attack.
+
+It also works for string inputs,like:
+```javascript
+var query = {
+ $where: "this.name === '" + req.body.name + "'"
+}
+```
+
+The attack could be the string **'\'; return \'\' == \''** and the where clause would be evaluated to **this.name === ''; return '' == ''**,that results in returning all users instead of only those who matches the clause.
+
+The solution here is to never use the $where operator.
+Why? I list it here:
+
+* Performance: since you can run arbitrary JavaScript code, the $where operator is not optimized. That means: indexes will be ignored.
+
+* Scope is not accessible: the solution to avoid the code injection would be to add the where clause inside a function, like the following:
+
+```javascript
+var query = {
+ $where : function() {
+ return.this.canceledOrders > threshold
+ }
+}
+```
+
+However, it won't work.
+The local variable value is not passed to Mongo and it returns the following error if executed in a shell
+
+```javascript
+Error: error: {
+ "$err" : "ReferenceError: threshold is not defined\n at _funcs2(_funcs2:1:45) near 's.canceledOrders > threshold }'",
+ "code" : 16722
+}
+```
+
+* There is always a better solution. In this case, you would use te operators **$eq** or **$gt**.
+
+
+## Rule Details
+
+This rule aims to...
+
+Examples of **incorrect** code for this rule:
+
+```js
+
+// fill me in
+
+```
+
+Examples of **correct** code for this rule:
+
+```js
+
+// fill me in
+
+```
+
+### Options
+
+If there are any options, describe them here. Otherwise, delete this section.
+
+## When Not To Use It
+
+Give a short description of when it would be appropriate to turn off this rule.
+
+## Further Reading
+
+If there are other links that describe the issue this rule addresses, please include them here in a bulleted list.
diff --git a/docs/description/security-node_detect-option-multiplestatements-in-mysql.md b/docs/description/security-node_detect-option-multiplestatements-in-mysql.md
new file mode 100644
index 000000000..0e1fafc79
--- /dev/null
+++ b/docs/description/security-node_detect-option-multiplestatements-in-mysql.md
@@ -0,0 +1,36 @@
+# detect option mulitpleStatements:true in createConnection method of mysql (detect-option-multiplestatements-in-mysql)
+
+Please describe the origin of the rule here.
+
+
+## Rule Details
+
+This rule aims to...
+
+Examples of **incorrect** code for this rule:
+
+```js
+
+// fill me in
+
+```
+
+Examples of **correct** code for this rule:
+
+```js
+
+// fill me in
+
+```
+
+### Options
+
+If there are any options, describe them here. Otherwise, delete this section.
+
+## When Not To Use It
+
+Give a short description of when it would be appropriate to turn off this rule.
+
+## Further Reading
+
+If there are other links that describe the issue this rule addresses, please include them here in a bulleted list.
diff --git a/docs/description/security-node_detect-option-rejectunauthorized-in-nodejs-httpsrequest.md b/docs/description/security-node_detect-option-rejectunauthorized-in-nodejs-httpsrequest.md
new file mode 100644
index 000000000..f99ed56ff
--- /dev/null
+++ b/docs/description/security-node_detect-option-rejectunauthorized-in-nodejs-httpsrequest.md
@@ -0,0 +1,36 @@
+# detect option rejectUnauthorized:false in Nodejs https request method (detect-option-rejectunauthorized-in-nodejs-httpsrequest)
+
+Please describe the origin of the rule here.
+
+
+## Rule Details
+
+This rule aims to...
+
+Examples of **incorrect** code for this rule:
+
+```js
+
+// fill me in
+
+```
+
+Examples of **correct** code for this rule:
+
+```js
+
+// fill me in
+
+```
+
+### Options
+
+If there are any options, describe them here. Otherwise, delete this section.
+
+## When Not To Use It
+
+Give a short description of when it would be appropriate to turn off this rule.
+
+## Further Reading
+
+If there are other links that describe the issue this rule addresses, please include them here in a bulleted list.
diff --git a/docs/description/security-node_detect-option-unsafe-in-serialize-javascript-npm-package.md b/docs/description/security-node_detect-option-unsafe-in-serialize-javascript-npm-package.md
new file mode 100644
index 000000000..ef6445d31
--- /dev/null
+++ b/docs/description/security-node_detect-option-unsafe-in-serialize-javascript-npm-package.md
@@ -0,0 +1,89 @@
+# detect opion:unsafe in serialize method in serialize-javasript npm package (detect-option-unsafe-in-serialize-javascript-npm-package)
+
+Serialize-javascript is a famous npm package that serializes javascript to a superset of JSON that includes regular expressions, dates and functions.
+
+### Automatic Escaping of HTML Characters
+A primary feature of this package is to serialize code to a string of literal JavaScript which can be embedded in an HTML document by adding it as the contents of the script element.
+In order to make this safe, HTML characters and JavaScript line terminators are escaped automatically.
+```javascript
+serialize({
+ haxorXSS: ''
+});
+```
+
+The above will produce the following string,HTML-escaped output which is safe to put into an HTML document as it will not cause the inline script element to terminate.
+```js
+'{"haxorXSS":"\\u003C\\u002Fscript\\u003E"}'
+```
+You can pass an optional unsafe argument to serialize() for straight serialization.
+
+### Options
+The serialize() function accepts an options object as its second argument.
+All options are being defaulted to undefined.
+
+### What about options.unsafe?
+This option is used to signal serialize() that we want to do a straight conversion, without the XSS protection.
+This options needs to be explicitly set to true.
+HTML characters and JavaScript line terminators will not be escaped.
+You will have to roll your own.
+
+```js
+serialize(obj,{unsafe:true});
+```
+
+### How does this HTML Injection Attack work in practice?
+
+Let's say we have a node.js web app.
+We’re running express.js and using ejs for our templating language.
+We’re fetching the name url param and injecting it into the ejs template.
+
+```js
+// routes/index.js
+router.get('/', function(req,res,next){
+ var name = req.query.name;
+ // we are passing the 'name' query to the template
+ res.render('index', {title: 'Home', name: name});
+});
+```
+
+```html
+//views/index.js template
+
+<%= title %>
+Welcome to <%= title %>
+Hi my name is <%- name %>
+
+```
+### The Attack
+So far so good. Nothing fishy going on here. Now let’s try to insert a
+```
+This is bad because we are allowing an (untrusted) user to execute any JavaScript they want on our page.
+
+### How can this attack hurt me?
+An alert box on a page is pretty harmless.
+So how could this hurt somebody?
+
+Here’s how an attacker could use this to get access to your bank account.
+
+* You’d receive an email with instructions to log into your bank
+
+* After login, you’re instructed to click on this link
+```js
+ https://yourBankWebsite.com/account?id=
+```
+When you log in, your bank’s website server starts a session for you (usually lasting 10–15 minutes, after which you are automatically logged out).
+The session information (usually called a token) is stored in a cookie on your computer.
+If the hacker can get you to log in, and then click the link he sent you, then maliciousCodeHere will run and could send your session token to the hacker.
+This allows him to steal your session.
+He could then (in theory) create a cookie on his computer and store your session information in it.
+If that session is still active, he can visit your bank's website, and he’ll be logged in as you, and can browse around, look at bank account information, and possibly even initiate a transfer or change your password.
+In summary, the hacker sent you a link, which caused you to run JavaScript in your browser, after you logged in, allowing him to steal protected information (in this case, the session token).
+This is dangerous because you are running unsafe JS after you’ve been given access to your sensitive info.
+
+
+
+## Further Reading
+[link 1](https://medium.com/@jamischarles/xss-aka-html-injection-attack-explained-538f46475f6c)
+[link 2](https://www.npmjs.com/package/serialize-javascript)
diff --git a/docs/description/security-node_detect-possible-timing-attacks.md b/docs/description/security-node_detect-possible-timing-attacks.md
new file mode 100644
index 000000000..9f060cc12
--- /dev/null
+++ b/docs/description/security-node_detect-possible-timing-attacks.md
@@ -0,0 +1,36 @@
+# detect possible timing attacks (detect-possible-timing-attacks)
+
+Please describe the origin of the rule here.
+
+
+## Rule Details
+
+This rule aims to...
+
+Examples of **incorrect** code for this rule:
+
+```js
+
+// fill me in
+
+```
+
+Examples of **correct** code for this rule:
+
+```js
+
+// fill me in
+
+```
+
+### Options
+
+If there are any options, describe them here. Otherwise, delete this section.
+
+## When Not To Use It
+
+Give a short description of when it would be appropriate to turn off this rule.
+
+## Further Reading
+
+If there are other links that describe the issue this rule addresses, please include them here in a bulleted list.
diff --git a/docs/description/security-node_detect-runinthiscontext-method-in-nodes-vm.md b/docs/description/security-node_detect-runinthiscontext-method-in-nodes-vm.md
new file mode 100644
index 000000000..28d68ab26
--- /dev/null
+++ b/docs/description/security-node_detect-runinthiscontext-method-in-nodes-vm.md
@@ -0,0 +1,54 @@
+# detect vm.runInThisContext() method in nodes vm (detect-runinthiscontext-method-in-nodes-vm)
+
+### Dive into VM's world
+With node.js VM you can run JS code in a new "node process" that has no access to the standard node library - no **process**, no **console**, just basic plain JS: that's what the vm module lets you do.
+
+Let's take a look at the following example:
+
+```js
+const vm = require('vm');
+let result = vm.runInNewContext('a + 1', {a: 2});
+console.log(result); // 3
+```
+
+Here we are asking Node to create a new V8 context and run a bunch of code (a + 1) there for us, passing an object that constitutes the global environment of that new context ({a: 2}).
+
+Note that the current execution context is not affected by what happens in that new context:
+
+```js
+let a = 0;
+let result = vm.runInNewContext('a += 1', {a});
+console.log(a) // a
+```
+
+unless you specifically tell the VM that you want to re-use an existing context or to use the current context with **vm.runInThisContext()**:
+
+```js
+a = 0;
+vm.runInThisContext('a += 1');
+console.log(a) // 1
+```
+When you use the current execution context (runInThisContext) the executed code is going to have access to globally-defined variables of the current context which, of course, exposes us to the same kind of problems we’d have with eval.
+
+
+
+
+Examples of **incorrect** code for this rule:
+
+```js
+
+// fill me in
+
+```
+
+Examples of **correct** code for this rule:
+
+```js
+
+// fill me in
+
+```
+
+
+## Further Reading
+[link 1](https://odino.org/eval-no-more-understanding-vm-vm2-nodejs/)
diff --git a/docs/description/security-node_detect-security-missconfiguration-cookie.md b/docs/description/security-node_detect-security-missconfiguration-cookie.md
new file mode 100644
index 000000000..8ae9c0a12
--- /dev/null
+++ b/docs/description/security-node_detect-security-missconfiguration-cookie.md
@@ -0,0 +1,41 @@
+# detect security missconfiguration in express cookie (detect-security-missconfiguration-cookie)
+This vulnerability allows an attacker to access default accounts, unused pages, unpatched flaws, unprotected files, and directories, etc. to gain unauthorized access to or knowledge of the system.
+
+Security misconfiguration can happen at any level of an application stack, including the platform, web server, application server, database, framework, and custom code.
+
+Developers and system administrators need to work together to ensure that the entire stack is configured properly.
+
+### Attack Mechanics
+If the server is misconfigured to leak internal implementation details via cookie names or HTTP response headers, then an attacker can use this information towards building site's risk profile and finding vulnerabilities
+
+### What about express-session?
+
+#### What is Express session used for?
+You can **use sessions** to communicate data to middleware that's executed later or retrieve it later on, on subsequent requests.
+Where is the session data stored? It depends on how you set up the express-session module.
+All solutions store the session id in a cookie and keep the data server-side.
+
+#### How does express session work?
+Until the cookie expires, every time you make a request, your browser will send the cookies back to the server.
+A module like express-session will provide you with a nice API to work with sessions (letting you get & set data to the session), but under the hood, it will save and retrieve this data using a cookie.
+
+#### "Security" options of express-session
+* **cookie.httpOnly**: Specifies the **boolean** value for the **HttpOnly Set-Cookie** attribute.
+When truthy, the HttpOnly attribute is set, otherwise, it is not.
+**By default**, the HttpOnly attribute **is set**.
+
+**Note**: Be careful when setting it to true, as compliant clients will not allow client-side JavaScript to see the cookie in document.cookie!
+
+So if this attribute is set, it prevents cookies from being accessed by browser JS scripts.
+
+* **cookie.secure**: Specifies the **boolean** value for the **Secure Set-Cookie** attribute.
+When truthy, the Secure attribute is set, otherwise it is not.**By default**, the Secure attribute is **not** set.
+
+**Note**: Be careful when setting this to true, as compliant clients will not send the cookie back to the server in the future if the browser does not have an **HTTPS** connection.
+
+So if this attribute is set, cookies can only be configured over secure HTTPS connections.
+
+
+## Further Reading
+[link 1](https://www.npmjs.com/package/express-session)
+[link 2](http://nodegoat.herokuapp.com/tutorial/a5)
diff --git a/docs/description/security-node_detect-sql-injection.md b/docs/description/security-node_detect-sql-injection.md
new file mode 100644
index 000000000..3f4cdcc4c
--- /dev/null
+++ b/docs/description/security-node_detect-sql-injection.md
@@ -0,0 +1,93 @@
+# detect SQL injection (detect-sql-injection)
+
+### Database Injection
+With a successful database injection, an attacker can execute malicious commands on a database to steal sensitive data, tamper with stored data, execute database administration operations, access contents of files present on the database filesystem, and, in some cases, issue commands to the host operating system.
+
+### SQL Injection Attack Mechanics
+Dynamic database queries that include user-supplied inputs are the primary target behind the SQL injection attack.
+When malicious data is concatenated to a SQL query, the SQL interpreter fails to distinguish between the intended command and input data, resulting in the execution of the malicious data as SQL commands.
+
+Let's consider a vulnerable SQL query, as shown in the example, that authenticates a user.
+
+```javascript
+connection.query(
+ 'SELSECT * FROM accounts WHERE username = "'
+ + req.body.username + '" AND password = "' + passwordHash + '"',
+ function(err, rows, fields) {
+ console.log("Result = " + JSON.stringify(rows));
+ });
+```
+
+The above example illustrates code that dynamically constructs a SQL query by appending the user-supplied request parameter username.
+To exploit this query, an attacker can enter admin' -- as a username, which ultimately results in executing the SQL query, as shown in the following Example
+
+```javascript
+SELECT * FROM accounts WHERE username = 'admin'
+```
+
+The malicious user input eliminated the need for an attacker to submit a correct password because the part after -- in a SQL query is interpreted a comment, thus skipping the password comparison.
+
+Another more destructive, variation of SQL injection is possible with databases that support batch execution of multiple statements when those statements are followed by a semicolon.
+
+For example, if an attacker enters the string admin'; DELETE FROM accounts; --as username, the resultant query is equivalent to two statements, as shown in the following example,
+
+Example: Resultant query containing multiple SQL injection
+```javascript
+SELECT * FROM accounts WHERE username = 'admin';
+DELETE FROM accounts;
+```
+
+This query results in removing all user accounts from the database.
+
+An attacker can use a wide variety of malicious inputs for concluding injection, such as the following:
+
+* 1' OR '1'='1 or its equivalent URL-encoded text 1%27%200R%20%271%27%20%3D%20%271 to get all records and ignore-the latter part of the WHERE clause
+
+* %in user input to match any substring or _ to match any character
+
+### Preventing SQL Injection
+The good news is that SQL injection is easy to prevent by using a few simple measures.
+
+### Use Pramaterized Queries To Bind All User-Supplied Data
+A parameterized query is considered a silver bullet for preventing the dreaded SQL injection.
+Parameterized queries prevent an attacker from changing the intent of a query, and enable the SQL interpreter to distinguish clearly between code and data.
+Hence, as shown in the following example, always bind all user inputs to the query with parameters.
+
+Example:
+```javascript
+var mysql = require('mysql');
+var bcrypt = require('bcrypt-nodejs');
+
+//Prepare query parameters
+var username = req.body.username;
+var passwordHash = bcrypt.hashSync(req.body.password,bcrypt.genSaltSync());
+
+//Make connection to the MySQL database
+var connection = mysql.createConnection({
+ host: 'localhost',
+ user: 'db_user',
+ password: 'secret',
+ database: 'node_app_db'
+});
+connection.connect();
+//Execute prepared statement with parameterized uesr inputs
+var query = 'SELECT * FROM accounts WHERE username=? AND password=?';
+connection.query(query, [username,passwordHash],
+function(err,rows,fields){
+ console.log("Results = " JSON.stringify(rows));
+});
+connection.end();
+```
+
+If an attacker enters the username as admin' --, the resultant query from the code in the above example would explicitly look for a username that matches the exact string admin' -- instead of admin, thus foiling the SQL injection attack.
+
+So what you can do?
+
+**You can use prepared Statements: For SQL calls, use prepared statements instead of building dynamic queries using string concatenation**
+
+That's exactly what this rule does! It checks for dynamic queries using string concatenation!
+
+
+## Further Reading
+[link 1](http://nodegoat.herokuapp.com/tutorial/a1)
+[link 2](https://www.oreilly.com/library/view/securing-node-applications/9781491982426)
diff --git a/docs/description/security-node_detect-unhandled-async-errors.md b/docs/description/security-node_detect-unhandled-async-errors.md
new file mode 100644
index 000000000..fe94cddab
--- /dev/null
+++ b/docs/description/security-node_detect-unhandled-async-errors.md
@@ -0,0 +1,64 @@
+# detect unhandled async errors (detect-unhandled-async-errors)
+
+It is impossible to have no errors in your program, even those of the best programmers have one way or another. There are some ways to handle errors in order to find and fix them.
+
+### try-catch method
+```javascript
+async function userProfile() {
+ try {
+ let user = await getUser();
+ let friendsOfUser = await getFriendsOfUser(userId);
+ let posts = await getUsersPosts(userId);
+
+ showUserProfilePage(user, friendsOfUser, posts);
+ } catch(e) {
+ console.log(e);
+ }
+}
+```
+Your code won't look too good having multiple request handlers each with a try/catch statement.
+
+### .catch method
+The .catch method can be used if we want to know which error comes from which async request.
+
+```javascript
+async function userProfile() {
+ let user = await getUser().catch(err => console.error('an error occurred'));
+ let friendsOfUser = await getFriendsOfUser(userId).catch(err => console.error('an error occurred'));
+ let posts = await getUsersPosts(userId).catch(err => console.error('an error occurred'));
+
+ showUserProfilePage(user, friendsOfUser, posts);
+}
+```
+
+### using a separate error handling function (Recommended)
+With error handler functions. Lessening the need for try-catch blocks and .catch methods.
+
+```javascript
+const handle = (promise) => {
+ return promise
+ .then(data => ([data, undefined]))
+ .catch(error => Promise.resolve([undefined, error]));
+}
+
+async function userProfile() {
+ let [user, userErr] = await handle(getUser());
+
+ if(userErr) throw new Error('Could not fetch user details');
+
+ let [friendsOfUser, friendErr] = await handle(
+ getFriendsOfUser(userId)
+ );
+
+ if(friendErr) throw new Error('Could not fetch user\'s friends');
+
+ let [posts, postErr] = await handle(getUsersPosts(userId));
+
+ if(postErr) throw new Error('Could not fetch user\'s posts');
+
+ showUserProfilePage(user, friendsOfUser, posts);
+}
+```
+
+[link 1](https://cheatsheetseries.owasp.org/cheatsheets/Nodejs_Security_Cheat_Sheet.html#handle-errors-in-asynchronous-calls)
+[link 2](https://dev.to/sobiodarlington/better-error-handling-with-async-await-2e5m)
\ No newline at end of file
diff --git a/docs/description/security-node_detect-unhandled-event-errors.md b/docs/description/security-node_detect-unhandled-event-errors.md
new file mode 100644
index 000000000..50fcf6770
--- /dev/null
+++ b/docs/description/security-node_detect-unhandled-event-errors.md
@@ -0,0 +1,30 @@
+# detect unhandled error events (detect-unhandled-error-events)
+
+When using the EventEmitter, it cannot be denied that errors can occur anywhere in the chain.
+
+Given this code below:
+```javascript
+const EventEmitter = require('events')
+const myEmitter = new EventEmitter()
+
+myEmitter.emit('error', new Error('whoops!'))
+// Throws and crashes Node.js
+```
+Since there is no error event listener called, the error will be thrown and will be treated as an uncaughtException. Once an error is emitted and unhandled, the Node.js application will crash.
+
+There should always be listeners for events at the least. This of course does not count out error events.
+
+```javascript
+const EventEmitter = require('events')
+const myEmitter = new EventEmitter()
+// MUST: include error listener
+myEmitter.on('error', (err) => {
+ console.error('An error occurred')
+})
+myEmitter.emit('error', new Error('whoops!'))
+// Prints: An error occurred
+```
+
+
+[link 1](https://nodejs.org/dist/latest-v16.x/docs/api/events.html#error-events)
+[link 2](https://cheatsheetseries.owasp.org/cheatsheets/Nodejs_Security_Cheat_Sheet.html#listen-to-errors-when-using-eventemitter)
\ No newline at end of file
diff --git a/docs/description/security-node_disable-ssl-across-node-server.md b/docs/description/security-node_disable-ssl-across-node-server.md
new file mode 100644
index 000000000..1fc173737
--- /dev/null
+++ b/docs/description/security-node_disable-ssl-across-node-server.md
@@ -0,0 +1,36 @@
+# process.env.NODE_TLS_REJECT_UNAUTHORIZED='0' disables SSL across node server! (disable-ssl-across-node-server)
+
+Please describe the origin of the rule here.
+
+
+## Rule Details
+
+This rule aims to...
+
+Examples of **incorrect** code for this rule:
+
+```js
+
+// fill me in
+
+```
+
+Examples of **correct** code for this rule:
+
+```js
+
+// fill me in
+
+```
+
+### Options
+
+If there are any options, describe them here. Otherwise, delete this section.
+
+## When Not To Use It
+
+Give a short description of when it would be appropriate to turn off this rule.
+
+## Further Reading
+
+If there are other links that describe the issue this rule addresses, please include them here in a bulleted list.
diff --git a/docs/description/security-node_non-literal-reg-expr.md b/docs/description/security-node_non-literal-reg-expr.md
new file mode 100644
index 000000000..137e7868b
--- /dev/null
+++ b/docs/description/security-node_non-literal-reg-expr.md
@@ -0,0 +1,41 @@
+# Non-literal regular expressions may cause possible attack (non-literal-reg-expr)
+
+### How a Regular Expression can bring your Node.js service down
+The use of Regular Expressions (RegEx) is quite common among software engineers and DevOps IT roles where they specify a string pattern to match a specific string in a text.
+
+Often, programmers will use RegEx to validate that an input received from a user conforms to an expected condition.
+For example:
+
+Testing that a user's provided e-mail address is valid:
+
+```js
+var testEmail = /^([a-zA-Z0-9])(([\-.]|[_]+)?([a-zA-Z0-9]+))*(@){1}[a-z0-9]+[.]{1}(([a-z]{2,3})|([a-z]{2,3}[.]{1}[a-z]{2,3}))$/.exec('john@example.com');
+```
+
+### What does it have to do with Node.js?
+The risk that is inherent with the use of Regular Expressions is the computational resources that require to parse text and match a given pattern.
+A flawed Regular Expression pattern can be attacked in a manner where a provided user input for text to match will require an outstanding amount of CPU cycles to process the RegEx execution.
+Such an attack will render a Node.js or JavaScript application unresponsive, and thus is referred to as a ReDoS — Regular Expression Denial of Service.
+
+
+## Rule Details
+
+This rule aims to detect non-literal RegExp that may contains user's input!
+
+Examples of **incorrect** code for this rule:
+
+```js
+RegExp('/\w+/' + input);
+// OR
+RegExp(input);
+```
+
+Examples of **correct** code for this rule:
+
+```js
+RegExp('/\w+/');
+```
+
+
+## Further Reading
+[link 1](https://medium.com/@liran.tal/node-js-pitfalls-how-a-regex-can-bring-your-system-down-cbf1dc6c4e02)
\ No newline at end of file
diff --git a/docs/description/suitescript_api-version.md b/docs/description/suitescript_api-version.md
new file mode 100644
index 000000000..74ed686a4
--- /dev/null
+++ b/docs/description/suitescript_api-version.md
@@ -0,0 +1,51 @@
+# suitescript/api-version
+
+Enforces valid `@NApiVersion` tag values in the header block comment of every SuiteScript file.
+
+Does not report missing `@NApiVersion` tags.
+
+## Rule Details
+
+Valid tag values are `1.0`, `2.x`, `2.0`, and `2.1`.
+
+:white_check_mark: Using one of these values, the following pattern is **correct**:
+
+```js
+/* eslint suitescript/api-version: "error" */
+
+/**
+ * @NApiVersion [value]
+ */
+```
+
+:x: The following patterns are **incorrect**:
+
+```js
+/* eslint suitescript/api-version: "error" */
+
+/**
+ * @NApiVersion
+ */
+```
+```js
+/* eslint suitescript/api-version: "error" */
+
+/**
+ * @NApiVersion2
+ */
+```
+```js
+/* eslint suitescript/api-version: "error" */
+
+/**
+ * @NApiVersion 2
+ */
+```
+
+## Version
+
+This rule was introduced in version 1.0.0.
+
+## Source
+
+- [Rule source](../../lib/rules/api-version.js)
\ No newline at end of file
diff --git a/docs/description/suitescript_entry-points.md b/docs/description/suitescript_entry-points.md
new file mode 100644
index 000000000..6173fbdc2
--- /dev/null
+++ b/docs/description/suitescript_entry-points.md
@@ -0,0 +1,127 @@
+# suitescript/entry-points
+
+Enforces the inclusion of at least one entry point based on the value provided in the `@NScriptType` tag. If no tag is provided, no entry point will be enforced.
+
+## Rule Details
+
+:white_check_mark: The following patterns are **correct**:
+
+```js
+/* eslint suitescript/entry-points: "error" */
+
+/**
+ * @NScriptType UserEventScript
+ */
+
+define([], function() {
+ return {
+ beforeLoad: function() {}
+ }
+});
+```
+```js
+/* eslint suitescript/entry-points: "error" */
+
+/**
+ * @NScriptType ClientScript
+ */
+
+define([], function() {
+ return {
+ pageInit: function() {},
+ somethingElse: function() {}
+ }
+});
+```
+```js
+/* eslint suitescript/entry-points: "error" */
+
+// No @NScriptType tag
+
+define([], function() {
+ return {
+ somethingElse: function() {}
+ }
+});
+```
+
+:x: The following patterns are **incorrect**:
+
+```js
+/* eslint suitescript/entry-points: "error" */
+
+/**
+ * @NScriptType UserEventScript
+ */
+
+define([], function() {});
+```
+```js
+/* eslint suitescript/entry-points: "error" */
+
+/**
+ * @NScriptType ClientScript
+ */
+
+define([], function() {
+ return {
+ somethingElse: function() {}
+ }
+});
+```
+
+### Script Types and Their Respective Entry Points
+
+- BundleInstallationScript
+ - afterInstall
+ - afterUpdate
+ - beforeInstall
+ - beforeUninstall
+ - beforeUpdate
+- ClientScript
+ - fieldChanged
+ - lineInit
+ - pageInit
+ - postSourcing
+ - saveRecord
+ - sublistChanged
+ - validateDelete
+ - validateField
+ - validateInsert
+ - validateLine
+ - localizationContextEnter
+ - localizationContextExit
+- MapReduceScript
+ - getInputData
+ - map
+ - reduce
+ - summarize
+- MassUpdateScript
+ - each
+- Portlet
+ - render
+- Restlet
+ - delete
+ - get
+ - post
+ - put
+- ScheduledScript
+ - execute
+- SDFInstallationScript
+ - run
+- Suitelet
+ - onRequest
+- UserEventScript
+ - afterSubmit
+ - beforeLoad
+ - beforeSubmit
+- WorkflowActionScript
+ - onAction
+
+## Version
+
+This rule was introduced in version 1.0.0.
+
+## Source
+
+- [Rule source](../../lib/rules/entry-points.js)
\ No newline at end of file
diff --git a/docs/description/suitescript_log-args.md b/docs/description/suitescript_log-args.md
new file mode 100644
index 000000000..2327ebfa1
--- /dev/null
+++ b/docs/description/suitescript_log-args.md
@@ -0,0 +1,81 @@
+# suitescript/log-args
+
+Enforces correct log arguments (title and details) in all `Log` methods.
+
+## Rule Details
+
+If no options are provided, the rule will require both title and details.
+
+:white_check_mark: The following patterns are **correct**:
+
+```js
+/* eslint suitescript/log-args: "error" */
+
+log.debug({ title: 'Title', details: 'Details' });
+```
+```js
+/* eslint suitescript/log-args: "error" */
+
+log.audit('Title', 'Details');
+```
+```js
+/* eslint suitescript/log-args: "error" */
+
+log.error('', 'Details');
+```
+
+:x: The following patterns are **incorrect**:
+
+```js
+/* eslint suitescript/log-args: "error" */
+
+log.debug('Title');
+```
+```js
+/* eslint suitescript/log-args: "error" */
+
+log.audit({ details: 'Details' });
+```
+
+## Rule Options
+
+```js
+'suitescript/log-args': [, {
+ requireTitle: ,
+ requireDetails:
+}]
+```
+
+> **Note**: Setting both options to `false` is the same as not using the rule at all. Setting both options to `true` is the same as not providing options.
+
+### `requireTitle`
+
+_default: true_
+
+Explicitly requires a `title` argument no matter what.
+
+```js
+/* eslint suitescript/log-args: ["error", { requireTitle: true }] */
+
+log.debug({ title: 'Title' });
+```
+
+### `requireDetails`
+
+_default: true_
+
+Explicitly requires a `details` argument no matter what.
+
+```js
+/* eslint suitescript/log-args: ["error", { requireDetails: true }] */
+
+log.debug({ details: 'Details' });
+```
+
+## Version
+
+This rule was introduced in version 1.0.0.
+
+## Source
+
+- [Rule source](../../lib/rules/log-args.js)
\ No newline at end of file
diff --git a/docs/description/suitescript_module-vars.md b/docs/description/suitescript_module-vars.md
new file mode 100644
index 000000000..2ba6799e7
--- /dev/null
+++ b/docs/description/suitescript_module-vars.md
@@ -0,0 +1,98 @@
+# suitescript/module-vars
+
+Enforces correct module identifiers for each configured module name.
+
+Requires at least one module name to be specified to take effect.
+
+## Rule Details
+
+:white_check_mark: The following patterns are **correct**:
+
+```js
+/* eslint suitescript/module-vars: ["error", { "N/record": "record" }] */
+
+define(['N/record'], function(record) {});
+```
+```js
+/* eslint suitescript/module-vars: ["error", { "N/ui/message": "message" }] */
+
+define(['N/ui/message'], function(message) {});
+```
+
+:x: The following patterns are **incorrect**:
+
+```js
+/* eslint suitescript/module-vars: ["error", { "N/record": "record" }] */
+
+define(['N/record'], function(rec) {});
+```
+```js
+/* eslint suitescript/module-vars: ["error", { "N/ui/serverWidget": "serverWidget" }] */
+
+define(['N/ui/serverWidget'], function(ui) {});
+```
+
+## Rule Options
+
+Specify at least one module name with a corresponding variable name.
+
+```js
+'suitescript/module-vars': [, {
+ moduleName:
+ ...
+}]
+```
+
+## Module Names
+
+- N/action
+- N/auth
+- N/cache
+- N/certificateControl
+- N/commerce/recordView
+- N/config
+- N/crypto
+- N/crypto/certificate
+- N/currency
+- N/currentRecord
+- N/email
+- N/encode
+- N/error
+- N/file
+- N/format
+- N/format/i18n
+- N/http
+- N/https
+- N/https/clientCertificate
+- N/keyControl
+- N/log
+- N/piremoval
+- N/plugin
+- N/portlet
+- N/query
+- N/record
+- N/redirect
+- N/render
+- N/runtime
+- N/search
+- N/sftp
+- N/sso
+- N/task
+- N/task/accounting/recognition
+- N/transaction
+- N/translation
+- N/ui/dialog
+- N/ui/message
+- N/ui/serverWidget
+- N/url
+- N/util
+- N/workflow
+- N/xml
+
+## Version
+
+This rule was introduced in version 1.0.0.
+
+## Source
+
+- [Rule source](../../lib/rules/module-vars.js)
\ No newline at end of file
diff --git a/docs/description/suitescript_no-amd-name.md b/docs/description/suitescript_no-amd-name.md
new file mode 100644
index 000000000..49f134616
--- /dev/null
+++ b/docs/description/suitescript_no-amd-name.md
@@ -0,0 +1,33 @@
+# suitescript/no-amd-name
+
+:wrench: _The `--fix` option on the command line can automatically fix some of the problems reported by this rule._
+
+Restricts naming of AMD modules.
+
+Naming AMD modules [should generally be avoided](https://requirejs.org/docs/whyamd.html#namedmodules) because compilers will handle the ID-ing of modules internally where necessary.
+
+## Rule Details
+
+:white_check_mark: The following pattern is **correct**:
+
+```js
+/* eslint suitescript/no-amd-name: "error" */
+
+define([], function() {});
+```
+
+:x: The following pattern is **incorrect**:
+
+```js
+/* eslint suitescript/no-amd-name: "error" */
+
+define('myModule', [], function() {});
+```
+
+## Version
+
+This rule was introduced in version 1.0.0.
+
+## Source
+
+- [Rule source](../../lib/rules/no-amd-name.js)
\ No newline at end of file
diff --git a/docs/description/suitescript_no-extra-modules.md b/docs/description/suitescript_no-extra-modules.md
new file mode 100644
index 000000000..108d0f94b
--- /dev/null
+++ b/docs/description/suitescript_no-extra-modules.md
@@ -0,0 +1,39 @@
+# suitescript/no-extra-modules
+
+Enforces an equal number of module literals and identifiers in the `define` call arguments.
+
+## Rule Details
+
+:white_check_mark: The following patterns are **correct**:
+
+```js
+/* eslint suitescript/no-extra-modules: "error" */
+
+define([], function() {});
+```
+```js
+/* eslint suitescript/no-extra-modules: "error" */
+
+define(['N/search'], function(search) {});
+```
+
+:x: The following patterns are **incorrect**:
+
+```js
+/* eslint suitescript/no-extra-modules: "error" */
+
+define(['N/file'], function(file, record) {});
+```
+```js
+/* eslint suitescript/no-extra-modules: "error" */
+
+define(['N/file', 'N/record'], function(file) {});
+```
+
+## Version
+
+This rule was introduced in version 1.0.0.
+
+## Source
+
+- [Rule source](../../lib/rules/no-extra-modules.js)
\ No newline at end of file
diff --git a/docs/description/suitescript_no-invalid-modules.md b/docs/description/suitescript_no-invalid-modules.md
new file mode 100644
index 000000000..6c9235b5e
--- /dev/null
+++ b/docs/description/suitescript_no-invalid-modules.md
@@ -0,0 +1,39 @@
+# suitescript/no-invalid-modules
+
+Enforces valid SuiteScript module names in the `define` array.
+
+## Rule Details
+
+:white_check_mark: The following patters are **correct**:
+
+```js
+/* eslint suitescript/no-invalid-modules: "error" */
+
+define(['N/record'], function(record) {});
+```
+```js
+/* eslint suitescript/no-invalid-modules: "error" */
+
+define(['N/https', 'N/search'], function(https, search) {});
+```
+```js
+/* eslint suitescript/no-invalid-modules: "error" */
+
+define(['customModule'], function(customModule) {});
+```
+
+:x: The following pattern is **incorrect**:
+
+```js
+/* eslint suitescript/no-invalid-modules: "error" */
+
+define(['N/somethingElse'], function(somethingElse) {});
+```
+
+## Version
+
+This rule was introduced in version 1.0.0.
+
+## Source
+
+- [Rule source](../../lib/rules/no-invalid-modules.js)
\ No newline at end of file
diff --git a/docs/description/suitescript_no-log-module.md b/docs/description/suitescript_no-log-module.md
new file mode 100644
index 000000000..da59ef85c
--- /dev/null
+++ b/docs/description/suitescript_no-log-module.md
@@ -0,0 +1,62 @@
+# suitescript/no-log-module
+
+Restricts loading of the N/log module in favor of global `log`.
+
+In most cases, global `log` can be used instead of the N/log module.
+
+## Rule Details
+
+By default, the N/log module is allowed in client scripts because there it is used to log to NetSuite where it would otherwise be impossible. See the rule options below to modify this.
+
+:white_check_mark: The following pattern is **correct**:
+
+```js
+/* eslint suitescript/no-log-module: "error" */
+
+define([], function() {
+ log.debug('Title', 'Details');
+});
+```
+
+:x: The following pattern is **incorrect**:
+
+```js
+/* eslint suitescript/no-log-module: "error" */
+
+define(['N/log'], function(log) {
+ log.debug('Title', 'Details');
+});
+```
+
+## Rule Options
+
+```js
+'suitescript/no-log-module': [, {
+ allowInClientScripts:
+}]
+```
+
+### `allowInClientScripts`
+
+_default: true_
+
+Allows the N/log module to be loaded in client scripts.
+
+```js
+/* eslint suitescript/no-log-module: ["error", { allowInClientScripts: false }] */
+
+/**
+ * @NScriptType ClientScript',
+ */
+define([], function() {
+ console.log("can't use N\log");
+});
+```
+
+## Version
+
+This rule was introduced in version 1.0.0.
+
+## Source
+
+- [Rule source](../../lib/rules/no-log-module.js)
\ No newline at end of file
diff --git a/docs/description/suitescript_no-module-extensions.md b/docs/description/suitescript_no-module-extensions.md
new file mode 100644
index 000000000..3e06c7c57
--- /dev/null
+++ b/docs/description/suitescript_no-module-extensions.md
@@ -0,0 +1,31 @@
+# suitescript/no-module-extensions
+
+:wrench: _The `--fix` option on the command line can automatically fix some of the problems reported by this rule._
+
+Restricts filename extensions on module dependencies.
+
+> **Note:** As of January 2021, there appears to be a NetSuite bug that intermittently causes an error (`SuiteScript 2.1 entry point scripts must implement one script type function..`) when attempting to upload script files that include dependencies with file extensions.
+
+## Rule Details
+
+:white_check_mark: The following pattern is **correct**:
+
+```js
+/* eslint suitescript/no-module-extensions: "error" */
+
+define(['./lib'], function(lib) {});
+```
+
+:x: The following pattern is **incorrect**:
+
+```js
+/* eslint suitescript/no-module-extensions: "error" */
+
+define(['./lib.js'], function(lib) {});
+```
+
+## Version
+
+This rule was introduced in version 1.0.3
+
+- [Rule source](../../lib/rules/no-module-extensions.js)
diff --git a/docs/description/suitescript_script-type.md b/docs/description/suitescript_script-type.md
new file mode 100644
index 000000000..c286ae8a1
--- /dev/null
+++ b/docs/description/suitescript_script-type.md
@@ -0,0 +1,65 @@
+# suitescript/script-type
+
+Enforces valid `@NScriptType` tag values in the header block comment of every SuiteScript file.
+
+Does not report missing `@NScriptType` tags.
+
+## Rule Details
+
+Valid tag values are found below.
+
+:white_check_mark: Using one of these values, the following pattern is **correct**:
+
+```js
+/* eslint suitescript/script-type: "error" */
+
+/**
+ * @NScriptType [value]
+ */
+```
+
+:x: The following patterns are **incorrect**:
+
+```js
+/* eslint suitescript/script-type: "error" */
+
+/**
+ * @NScriptType
+ */
+```
+```js
+/* eslint suitescript/script-type: "error" */
+
+/**
+ * @NScriptTypeSuitelet
+ */
+```
+```js
+/* eslint suitescript/script-type: "error" */
+
+/**
+ * @NScriptType Client
+ */
+```
+
+## Script Types
+
+- BundleInstallationScript
+- ClientScript
+- MapReduceScript
+- MassUpdateScript
+- Portlet
+- Restlet
+- ScheduledScript
+- SDFInstallationScript
+- Suitelet
+- UserEventScript
+- WorkflowActionScript
+
+## Version
+
+This rule was introduced in version 1.0.0.
+
+## Source
+
+- [Rule source](../../lib/rules/script-type.js)
\ No newline at end of file
diff --git a/docs/description/unicorn_no-array-for-each.md b/docs/description/unicorn_no-array-for-each.md
index cbabb9ad1..9e9064208 100644
--- a/docs/description/unicorn_no-array-for-each.md
+++ b/docs/description/unicorn_no-array-for-each.md
@@ -13,6 +13,8 @@ Benefits of [`for…of` statement](https://developer.mozilla.org/en-US/docs/Web/
- Better readability
- Ability to exit early with `break` or `return`
+Additionally, using `for…of` has great benefits if you are using TypeScript, because it does not cause a function boundary to be crossed. This means that type-narrowing earlier on in the current scope will work properly while inside of the loop (without having to re-type-narrow). Furthermore, any mutated variables inside of the loop will picked up on for the purposes of determining if a variable is being used.
+
## Fail
```js
diff --git a/docs/description/vue_block-order.md b/docs/description/vue_block-order.md
new file mode 100644
index 000000000..a5007eda6
--- /dev/null
+++ b/docs/description/vue_block-order.md
@@ -0,0 +1,198 @@
+---
+pageClass: rule-details
+sidebarDepth: 0
+title: vue/block-order
+description: enforce order of component top-level elements
+since: v9.16.0
+---
+# vue/block-order
+
+> enforce order of component top-level elements
+
+- :wrench: The `--fix` option on the [command line](https://eslint.org/docs/user-guide/command-line-interface#fixing-problems) can automatically fix some of the problems reported by this rule.
+
+## :book: Rule Details
+
+This rule warns about the order of the top-level tags, such as `
+...
+
+```
+
+
+
+
+
+```vue
+
+...
+
+
+```
+
+
+
+
+
+```vue
+
+
+
+...
+```
+
+
+
+### `{ "order": ["template", "script", "style"] }`
+
+
+
+```vue
+
+...
+
+
+```
+
+
+
+
+
+```vue
+
+
+...
+
+```
+
+
+
+### `{ "order": ["docs", "template", "script", "style"] }`
+
+
+
+```vue
+
+ documentation
+...
+
+
+```
+
+
+
+
+
+```vue
+
+...
+
+ documentation
+
+```
+
+
+
+### `{ 'order': ['template', 'script:not([setup])', 'script[setup]'] }`
+
+
+
+```vue
+
+...
+
+
+```
+
+
+
+
+
+```vue
+
+...
+
+
+```
+
+
+
+### `{ 'order': ['template', 'style:not([scoped])', 'style[scoped]'] }`
+
+
+
+```vue
+
+...
+
+
+```
+
+
+
+
+
+```vue
+
+...
+
+
+```
+
+
+
+### `{ 'order': ['template', 'i18n:not([locale=en])', 'i18n[locale=en]'] }`
+
+
+
+```vue
+
+...
+/* ... */
+/* ... */
+```
+
+
+
+
+
+```vue
+
+...
+/* ... */
+/* ... */
+```
+
+
+
+## :books: Further Reading
+
+- [Style guide - Single-file component top-level element order](https://vuejs.org/style-guide/rules-recommended.html#single-file-component-top-level-element-order)
+
+## :rocket: Version
+
+This rule was introduced in eslint-plugin-vue v9.16.0
+
+## :mag: Implementation
+
+- [Rule source](https://github.com/vuejs/eslint-plugin-vue/blob/master/lib/rules/block-order.js)
+- [Test source](https://github.com/vuejs/eslint-plugin-vue/blob/master/tests/lib/rules/block-order.js)
diff --git a/docs/description/vue_component-tags-order.md b/docs/description/vue_component-tags-order.md
index 4fc8d245e..22b161aa0 100644
--- a/docs/description/vue_component-tags-order.md
+++ b/docs/description/vue_component-tags-order.md
@@ -9,6 +9,7 @@ since: v6.1.0
> enforce order of component top-level elements
+- :no_entry_sign: This rule was **deprecated** and replaced by [vue/block-order](block-order.md) rule.
- :gear: This rule is included in `"plugin:vue/vue3-recommended"` and `"plugin:vue/recommended"`.
- :wrench: The `--fix` option on the [command line](https://eslint.org/docs/user-guide/command-line-interface#fixing-problems) can automatically fix some of the problems reported by this rule.
diff --git a/docs/description/vue_no-deprecated-model-definition.md b/docs/description/vue_no-deprecated-model-definition.md
new file mode 100644
index 000000000..b0c0087ee
--- /dev/null
+++ b/docs/description/vue_no-deprecated-model-definition.md
@@ -0,0 +1,80 @@
+---
+pageClass: rule-details
+sidebarDepth: 0
+title: vue/no-deprecated-model-definition
+description: disallow deprecated `model` definition (in Vue.js 3.0.0+)
+since: v9.16.0
+---
+# vue/no-deprecated-model-definition
+
+> disallow deprecated `model` definition (in Vue.js 3.0.0+)
+
+- :bulb: Some problems reported by this rule are manually fixable by editor [suggestions](https://eslint.org/docs/developer-guide/working-with-rules#providing-suggestions).
+
+## :book: Rule Details
+
+This rule reports use of the component `model` option, which has been deprecated in Vue.js 3.0.0+.
+
+See [Migration Guide – `v-model`](https://v3-migration.vuejs.org/breaking-changes/v-model.html) for more details.
+
+
+
+```vue
+
+```
+
+
+
+## :wrench: Options
+
+```json
+{
+ "vue/no-deprecated-model-definition": ["error", {
+ "allowVue3Compat": true
+ }]
+}
+```
+
+### `"allowVue3Compat": true`
+
+Allow `model` definitions with prop/event names that match the Vue.js 3.0.0+ `v-model` syntax, i.e. `modelValue`/`update:modelValue` or `model-value`/`update:model-value`.
+
+
+
+```vue
+
+```
+
+
+
+## :couple: Related Rules
+
+- [vue/valid-model-definition](./valid-model-definition.md) (for Vue.js 2.x)
+- [vue/no-v-model-argument](./no-v-model-argument.md) (for Vue.js 2.x)
+
+## :books: Further Reading
+
+- [Migration Guide – `v-model`](https://v3-migration.vuejs.org/breaking-changes/v-model.html)
+
+## :rocket: Version
+
+This rule was introduced in eslint-plugin-vue v9.16.0
+
+## :mag: Implementation
+
+- [Rule source](https://github.com/vuejs/eslint-plugin-vue/blob/master/lib/rules/no-deprecated-model-definition.js)
+- [Test source](https://github.com/vuejs/eslint-plugin-vue/blob/master/tests/lib/rules/no-deprecated-model-definition.js)
diff --git a/docs/description/vue_no-dupe-keys.md b/docs/description/vue_no-dupe-keys.md
index 41f4a962f..1d9d20f24 100644
--- a/docs/description/vue_no-dupe-keys.md
+++ b/docs/description/vue_no-dupe-keys.md
@@ -11,11 +11,12 @@ since: v3.9.0
- :gear: This rule is included in all of `"plugin:vue/vue3-essential"`, `"plugin:vue/essential"`, `"plugin:vue/vue3-strongly-recommended"`, `"plugin:vue/strongly-recommended"`, `"plugin:vue/vue3-recommended"` and `"plugin:vue/recommended"`.
-This rule prevents to use duplicated names.
+This rule prevents using duplicate key names.
## :book: Rule Details
-This rule is aimed at preventing duplicated property names.
+This rule prevents duplicate `props`/`data`/`methods`/etc. key names defined on a component.
+Even if a key name does not conflict in the `
+```
+
+
+
+Destructuring the `props` passed to `setup` will cause the value to lose reactivity.
+
+
+
+```vue
+
+```
+
+
+
+Also, destructuring in root scope of `setup()` should error, but ok inside nested callbacks or returned render functions:
+
+
+
+```vue
+
+```
+
+
+
+## :wrench: Options
+
+Nothing.
+
+## :books: Further Reading
+
+- [Guide - Composition API - Setup](https://vuejs.org/api/composition-api-setup.html)
+- [Vue RFCs - 0013-composition-api](https://github.com/vuejs/rfcs/blob/master/active-rfcs/0013-composition-api.md)
+
+## :rocket: Version
+
+This rule was introduced in eslint-plugin-vue v9.17.0
+
+## :mag: Implementation
+
+- [Rule source](https://github.com/vuejs/eslint-plugin-vue/blob/master/lib/rules/no-setup-props-reactivity-loss.js)
+- [Test source](https://github.com/vuejs/eslint-plugin-vue/blob/master/tests/lib/rules/no-setup-props-reactivity-loss.js)
diff --git a/docs/description/vue_no-use-v-else-with-v-for.md b/docs/description/vue_no-use-v-else-with-v-for.md
new file mode 100644
index 000000000..7cfbf762d
--- /dev/null
+++ b/docs/description/vue_no-use-v-else-with-v-for.md
@@ -0,0 +1,57 @@
+---
+pageClass: rule-details
+sidebarDepth: 0
+title: vue/no-use-v-else-with-v-for
+description: disallow using `v-else-if`/`v-else` on the same element as `v-for`
+since: v9.16.0
+---
+# vue/no-use-v-else-with-v-for
+
+> disallow using `v-else-if`/`v-else` on the same element as `v-for`
+
+## :book: Rule Details
+
+This rule reports elements that have both `v-else-if`/`v-else` and `v-for` directives. That is valid in Vue (`v-else-if`/`v-else` will take precedence), but is confusing to read.
+
+
+
+```vue
+
+
+ foo
+
+ {{ x }}
+
+
+ {{ x }}
+
+
+
+ foo
+ {{ x }}
+ {{ x }}
+
+```
+
+
+
+## :wrench: Options
+
+Nothing.
+
+## :mute: When Not To Use It
+
+If you don't find using `v-else-if`/`v-else` together with `v-for` confusing to read, you can safely disable this rule.
+
+## :couple: Related Rules
+
+- [vue/no-use-v-if-with-v-for](./no-use-v-if-with-v-for.md)
+
+## :rocket: Version
+
+This rule was introduced in eslint-plugin-vue v9.16.0
+
+## :mag: Implementation
+
+- [Rule source](https://github.com/vuejs/eslint-plugin-vue/blob/master/lib/rules/no-use-v-else-with-v-for.js)
+- [Test source](https://github.com/vuejs/eslint-plugin-vue/blob/master/tests/lib/rules/no-use-v-else-with-v-for.js)
diff --git a/docs/description/vue_require-typed-object-prop.md b/docs/description/vue_require-typed-object-prop.md
new file mode 100644
index 000000000..85626791e
--- /dev/null
+++ b/docs/description/vue_require-typed-object-prop.md
@@ -0,0 +1,54 @@
+---
+pageClass: rule-details
+sidebarDepth: 0
+title: vue/require-typed-object-prop
+description: enforce adding type declarations to object props
+since: v9.16.0
+---
+# vue/require-typed-object-prop
+
+> enforce adding type declarations to object props
+
+- :bulb: Some problems reported by this rule are manually fixable by editor [suggestions](https://eslint.org/docs/developer-guide/working-with-rules#providing-suggestions).
+
+## :book: Rule Details
+
+Prevent missing type declarations for non-primitive object props in TypeScript projects.
+
+
+
+```vue
+
+```
+
+
+
+## :wrench: Options
+
+Nothing.
+
+## :mute: When Not To Use It
+
+When you're not using TypeScript in the project.
+
+## :rocket: Version
+
+This rule was introduced in eslint-plugin-vue v9.16.0
+
+## :mag: Implementation
+
+- [Rule source](https://github.com/vuejs/eslint-plugin-vue/blob/master/lib/rules/require-typed-object-prop.js)
+- [Test source](https://github.com/vuejs/eslint-plugin-vue/blob/master/tests/lib/rules/require-typed-object-prop.js)
diff --git a/docs/description/vue_script-setup-uses-vars.md b/docs/description/vue_script-setup-uses-vars.md
index f4d68926a..a26a19f60 100644
--- a/docs/description/vue_script-setup-uses-vars.md
+++ b/docs/description/vue_script-setup-uses-vars.md
@@ -9,7 +9,7 @@ since: v7.13.0
> prevent `