diff --git a/app/api/owasp-api-top-10-vulnerabilities.md b/app/api/owasp-api-top-10-vulnerabilities.md
new file mode 100644
index 000000000..534754620
--- /dev/null
+++ b/app/api/owasp-api-top-10-vulnerabilities.md
@@ -0,0 +1,17 @@
+| OWASP API Top 10 vulnerability | NodeGoat functionality / endpoint | Explanation | How to prevent |
+|--------------------------------|-----------------------------------|-------------| ---------------|
+| API1:2019 Broken Object Level Authorization | `GET /allocations/:userId` | Attacker can change userId parameter in URL and reveal that requested resource is available for everyone, not only for logged in user who is the owner of the resources. | Verify that requested ID in URL matches userId within current session.
+| API2:2019 Broken User Authentication | `POST /signup` & weak password | Allows to set up weak passwords which can be easily hacked using simple brute force / dictionary attacks. | Set up password policy that requires at least 8 characters including digit, special character & both lower and upper case letters.
+| API2:2019 Broken User Authentication | `POST /signup` & saving plaintext passwords | Storing passwords in plaintext may lead to credential stuffing when attacker gets access to database. In combination with API1 and API3 vulnerabilities, it may also lead to returning plaintext passwords to unauthorised attacker giving access to other users' accounts immediately. | Use strong hashing algorithm and store only hashed passwords.
+| API2:2019 Broken User Authentication | `POST /login?username=User1&password=passw0rd` | Sending credentials in URL exposes vulnerable information in system logs and are easily exploitable during DNS resolving. | Sent credentials as `BODY` payload. 
+| API3:2019 Excessive Data Exposure | `GET /profile` | Returning all fields from database without filtering sensitive data on server side, assuming it will be filtered by client. E.g. passwords (which could be saved in plaintext as described in API2 vulnerability), roles (e.g. `isAdmin`), or special flags (e.g. `isVip`)  | Pick only those properties you want to return, e.g. based on schema validation (it also helps maintaining API documentation for applications that use NoSQL databases). Validate user permissions/roles for requested resources.
+| API4:2019 Lack of Resources & Rate Limiting | Implement global rate limiting for all endpoints to prevent DoS and brute force attacks. | Without rate-limiting attacker can use brute force methods to guess users passwords or cause Denial Of Service on purpose. | a) Implement rate-limiting (e.g. using [`express-rate-limit`](https://www.npmjs.com/package/express-rate-limit) package), b) prevent brute force attacks by enforcing filling captcha on client side after Nth unsuccessful login attempt.
+| API4:2019 Lack of Resources & Rate Limiting | `POST /login` & hashed passwords | Attacker can find out that API response times are different when entered incorrect username and incorrect password. That could indicate that service is first checking for user existence and compares password hashes only if user is found. That in turn can be used by attacker to monitor response time when performing [credential stuffing](https://owasp.org/www-community/attacks/Credential_stuffing) attack to find valid usernames. | Always hash input password and compare with stored value in database (even if string sent is empty), then check if username is correct.
+| API5:2019 Broken Function Level Authorization | `GET /benefits` | User with no permissions is able to access administrator's endpoints. | Check if currently signed in user is admin. If certain endpoints are meant to never be disclosed to end user, HTTP `404 Not Found` status code can be used instead `HTTP 403 Forbidden` (ref. [W3C](https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.4))
+| API6:2019 Mass Assignment | `POST (PUT)  /profile` | If application updates user profile by simply assigning whole request body to MongoDB's `$set` object, attacker can use that to change his permissions (e.g. by setting `isAdmin` flag to `true`). Combined with API1 (Broken Object Level Authorization), attacker can change other users passwords. | Cherry-pick from request body only those properties that can be updated and explicitly assigned them in `$set` object.
+| API7:2019 Security Misconfiguration | General server configuration in `server.js` | Proper configuration of express application is often neglected - default, insecure configuration is used even for application deployed to production. This includes: <br> a) Using insecure `HTTP` protocol instead of `HTTPS`. <br> b) Using not updated packages with exposed vulnerabilities. <br> c) Not sending security directives to client. <br> d) CORS policy incorrectly set.  |- Make sure only HTTPS traffic is allowed; <br>- set correctly CORS policy and [Security Headers](https://owasp.org/www-project-secure-headers/); <br>- provide example of NPM package that was exploited and outdated version is being used.
+| API8:2019 Injection | `DELETE /profile/:id` (functionality not yet implemented) | No validating incoming parameters and using them directly in queries can lead to injecting malicious code that will be executed directly in database. E.g. Using `id` parameter directly in Mongo query to delete document ( `users.remove({ _id: req.params.id })` ) can be exploited by sending `[$ne]=null` string ( `DELETE /profile/[$ne]=null` ) which will lead to deleting all documents. | Validate and sanitize all incoming values. E.g. using `parseInt()` methods or testing with *safe* regex (*safe* in terms it's not exploitable by [ReDoS attack](https://owasp.org/www-community/attacks/Regular_expression_Denial_of_Service_-_ReDoS).
+| API9:2019 Improper Assets Management | `/api/beta/*` endpoints | Sometimes application exposes multiple API versions under the same host but different path, e.g. `example.com/api/v1/*` or `example.com/api/beta/*`. If for some reasons (e.g. simplifying QA testing process) some security mechanisms are disabled for older/beta routes, attacker may go around rate-limiting or captcha mechanism that are implemented in production endpoints that were preventing DoS and brute force attacks. | Carefully manage all exposed endpoints. If some mechanisms need to be disabled, make sure it's available only to users which were explicitly granted access to.
+| API10:2019 Insufficient Logging & Monitoring | `POST /login` <br> `POST /admin/*` | Not sufficient logging will allow attacker to work being unexposed, e.g. performing brute force attacks with request intervals big enough to trick rate-limiting mechanism. | Add detailed log messages (keeping in mind not to logged user sensitive data) to the most important areas in application (authentication and authorization endpoints, user management, payments, etc.). 
+
+