Security Misconfiguration

# Security Misconfiguration

Your system is only as secure as you configure it to be. Mistakes in security configuration can disable authentication or authorization checks, leave default credentials in place at runtime, expose system information through error messages, or allow attackers access to confidential information on your server. Make sure to double-check any configuration files deployed to production environments.

Below are some key aspects to check when securing your configuration

## Keep Configuration Values Out Of Source Code

Configuration should be kept in configuration files, or a dedicated configuration store. This makes it easy to have separate configuration for development, test and production environments – and ensures no credentials are leaked if an attacker gets hold of your source code.

A common way of handling configuration in Node.js is to use the `dotenv` module to load configuration values held in an `.env` file:

“`javascript
DB_HOST=localhost
DB_USER=admin
DB_PASS=a9470df7-1f8f-49a7-8f8f-935ebe2e8ecc
“`

This configuration file can be loaded as follows:

“`javascript
require(‘dotenv’).config()const db = require(‘db’)

db.connect({
host: process.env.DB_HOST,
username: process.env.DB_USER,
password: process.env.DB_PASS
})
“`

## Disable Default Credentials In All Environments

Web-servers and databases often come with default credentials to make deployment easier. Make sure these are disabled in any internet-facing environments, and created dedicated accounts (with secure, unguessable passwords) in each environment.

## Secure Your Production Web-Server

Your production web-server should be configured securely. Here are some things you should do:

* Enforce use of HTTPS rather than HTTP by setting the `Strict-Transport-Security` header, so the browser knows to perform an HTTPS upgrade whenever an HTTP connection in initiated.

“`javascript
const express = require(‘express’)
const app = express()if (process.env.NODE_ENV === ‘production’) {
// Enforce HTTPS on all requests, setting the header with a max-age of 2 years.
app.use((request, response, next) => {
response.setHeader(
‘Strict-Transport-Security’,
‘max-age=’ + (60 * 60 * 24 * 365 * 2) + “; includeSubDomains; preload”
)

next()
})
}
“`

* Disable client-side error reporting, and return generic error messages to the user instead.

* Make sure cookies can’t be accessed in JavaScript (by adding the `HttpOnly` keyword) and only get passed over HTTPS (by adding the `Secure` keyword). Add the `SameSite` attribute to your cookies to protect against cross-site request forgery.

“`javascript
const cookieParser = require(‘cookie-parser’)
const express = require(‘express’)
const session = require(“express-session”);
const uid = require(“uid-safe”);const app = express()

app.use(cookieParser(‘secret’))
app.use(session({
cookie : {
maxAge : 60000,
httpOnly : true,
sameSite : ‘strict’,
secure : process.env.NODE_ENV === ‘production’
},

name : ‘session’,
secret : process.env.SESSION_SECRET || uid.sync(18)
}))
“`

* Set a `Content-Security` header on all responses to protect against cross-site scripting attacks.

“`javascript
const express = require(‘express’)
const app = express()// Only allow JavaScript to be loaded from our domain and google.com
app.use((request, response, next) => {
response.setHeader(“Content-Security-Policy”, “script-src ‘self’ https://apis.google.com”)
next()
})
“`

* Keep static content in a dedicated directory, and make sure your web-server only serves client-side content from that directory.

## Further Considerations

* Be sure to segregate your environments: environments should not share resources (like databases) and, as far possible, try to prevent network connections between environments.

* Ensure your build process is automated, and software dependencies are pinned to specific versions in your manifest files, so you know what versions of each dependency you are running in a given environment.

* Follow the *principle of least privilege*: connect to your database with only the permissions you need, and ensure the web-server process can only read and write to the directories it needs to. Never run processes under a root account.

## CWEs

* [CWE-209](https://cwe.mitre.org/data/definitions/209.html)
* [CWE-548](https://cwe.mitre.org/data/definitions/548.html)

Security Misconfiguration