Security is an illusion and being secure is a relative matter.

This means you

should always have an eye on your security from any perspective: Physical, human,
social, corporate and IT security. Since any system, given enough resources —
knowledge, tools and time, can be hacked.

My goal of writing this to show you how to approach and do a systematic secure code
review and penetration testing for securing your Node.js and JavaScript apps which
are very widespread nowadays. This being abundant enables attackers to have
enormous amount of systems that are written in this language and that run on
Node.js, browser and the like.

There are two different approaches on this: a) Secure Code Review as a defensive
approach to find flaws in a system and trying to secure it. b) Penetration Testing
as an offensive approach to find vulnerabilities and weaknesses on a live system.

A. Secure Code Review

Security code review is the process of auditing the source code for an application
to verify that the proper security controls are present, that they work as
intended, and that they have been invoked in all the right places. Code review is a
way of ensuring that the application has been developed so as to be “self-
defending” in its given environment. — OWASP Code Review Introduction

As you see, it’s all about auditing, verification and analysis. The OWASP community
has proposed a good starting point to do this job. It is called “The OWASP Code
Review Project”. It is an technical guide to help the code reviewers find the most
flaws under a unified framework.

Two versions of this technical guide is published and version 2.0 being the most
recent one, which was published 14 July 2017. The second version, which is
thoroughly updated, consists of an introduction to the subject matter, a
methodology and a set of technical references for the “OWASP Top 10” things to look
for while reviewing code. Various diagrams, methods, risk models and techniques has
been discussed. It is argued that the code review process should be a integrated
into the Software Development Life-cycle (SDLC), from pre-commit to post-commit
phases. Then a risk-based approach to code review has been proposed which tries to
anlayze risk with different techniques. A set of code review preparation steps
follows a set of static analysis tools. The last part show the S-SDLC as an
“Application Threat Modeling” approach which consists of three steps:

Step 1: Decompose the application.

Step 2: Determine and rank threats.
Step 3: Determine countermeasures and mitigation.

Some tools for threat modeling has also been discussed. Lastly, a set of metrics
are shown that can help the reviewer with quality and security characteristics of
the code-base. Thereafter the code crawling practice is briefly introduced.

The technical reference section consists of the top 10 topics to consider while
reviewing code:

A1-Injection
A2-Broken Authentication and Session Management
A3-Cross-Site Scripting (XSS)
A4-Insecure Direct Object Reference
A5-Security Misconfiguration
A6-Sensitive Data Exposure
A7-Missing Functional Level Access Control
A8-Cross-Site Request Forgery (CSRF)
A9-Using Components with Known Vulnerabilities
A10-Unvalidated Redirects and Forwards

This list is partly on par with what is known as the “OWASP Top 10 Project”, with
some minor differences, which I do recommend both of these guides to anyone who
wants to review code systematically, find flaws and eventually secure the system.

B. Penetration Testing
The second part, after reviewing code, is the penetration testing, which also
consists of a set of steps to find and pinpoint vulnerabilities and weaknesses from
an attacker’s point of view. Basically, you hack to secure!

A penetration test, colloquially known as a pen test, is an authorized simulated

cyber-attack on a computer system, performed to evaluate the security of the
system. — Wikipedia, Penetration test