MEAN Stack: How To Address Key Vulnerabilities

MEAN stack (MongoDB, ExpressJS, AngularJS, and NodeJS) applications are quite popular among developers these days. This phenomenon can be attributed to the fact that it’s an easily deployable lightweight framework that’s supported by a vast ecosystem of middleware plugins and dependencies.

However, the MEAN stack is by no means perfect as there are some common vulnerabilities that need to be addressed. These are usually the result of mistakes made by developers or the fact that they have used these components in their default configuration.

As a result, developers will have to make critical considerations when it comes to testing and security (which they might not have done before). This means that there needs to be a shift in the mindset of developers towards overall security.

Why now?

Working with a full MEAN stack provides deep exposure into all the layers of the stack, which makes it the developer’s responsibility to maintain the application’s cyber security posture. Furthermore, this also makes it imperative for developers to understand the risks and security implications of each technology component.

For example, the MEAN stack is streamlined for performance and all the layers of the stack are written in JavaScript. So developers only need to code front to back and the client server is in JavaScript. But since security is also their responsibility, they must validate each layer of the application for security.

So how do MEAN stack developers address key vulnerabilities while building apps? Let’s take a look.

First, let’s address vulnerabilities in MongoDB

MongoDB is a lot like HBase and Cassandra and is a JavaScript-friendly document-oriented NoSQL database. For the most part, MongoDB can be used just like MySQL, but it’s not immune to SQL injection-type of attacks.

Although MongoDB isn’t sensitive to SQL language abuses, its JSON documents can be vulnerable to malicious alterations. What’s more, MongoDB also has its own share of security risks as evidenced by Common Vulnerabilities and Exposures (CVE) database.

Next, let’s lock down ExpressJS

The server-side web and mobile application framework for NodeJS is ExpressJS. The framework is built upon NodeJS to streamline development and provide standard components.

It’s the most common and widely used NodeJS framework at present, but at the same time, it’s quite vulnerable to a variety of injections and cross-site attacks. This can make applications highly susceptible to all of NodeJS’ underlying vulnerabilities.

To stay on top of the list of vulnerabilities, developers will need to keep track of ExpressJS security updates.

Furthermore, the Express framework enables developers to seamlessly add multiple middleware plugins globally to all routes via app.use function. But the order of the middleware is important as it will only be applied to the routes defined further down the stack.

Check out: How to Interview a MEAN Stack Developer.

It’s also vital to note that the Express server framework will allow developers to easily define routes for serving RESTful APIs or static pages, but all these routes are case-sensitive by default. As a result, there can be problems when applying middleware security controls to routes that are based on traditional expression matching.

For example, as Express routes aren’t case sensitive, a request for /SECURE/manageInvoices will return the identical resource as /secure/manageInvoices. But the authentication checking middleware won’t be applied to /SECURE/manageInvoices, so an attacker will be able to gain access to the page without logging in.

Keeping AngularJS secure from cross — site attacks

AngularJS is a front-end MVC framework that is developed and maintained by Google to enable modular client-side development with the least amount of code. This framework is also susceptible to various cross-site scripting attacks.

Continue reading in Intersog blog

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.