DEV Community: Hejun Wong

Decoding MongoDB Metrics: A Practical Guide for DBAs, Developers and DevOps Engineers

Hejun Wong — Wed, 27 Aug 2025 04:07:30 +0000

When you're new to MongoDB, diving into the monitoring dashboard can feel like trying to read a foreign language. You're met with a sea of charts and numbers, but what do they all mean? What's good? What's bad? What demands immediate attention?

This is a critical skill for anyone managing or building on MongoDB, from DBAs and DevOps engineers to developers. Understanding these metrics is the key to proactive performance tuning, efficient resource provisioning, and preventing outages before they happen.

Over the years, I've spent a lot of time walking new team members, customers, and SREs through these charts. This article is my attempt to distill that knowledge and help you understand your MongoDB deployment's health a little better.

Let's demystify some of the most important metrics you should be watching.

Core Performance Indicators

These metrics give you a high-level overview of the database's workload and responsiveness.

1. OpCounters

While OpCounters (operation counters) don't directly signal a health problem, they provide essential context. This metric breaks down the database operations (insert, query, update, delete, etc.) happening over a specific period. By itself, it tells you what the database is doing. When correlated with other metrics like CPU or disk I/O, it helps you understand why the system is behaving a certain way.

2. Operation Execution Times

This chart shows the average time, in milliseconds, that database operations take to execute.

Good: Low values. This indicates your database is processing requests efficiently.
Bad: Rising values or Spikes. Increasing execution times are a clear signal of performance degradation. This could be due to inefficient queries, resource contention, or network issues.

By default, MongoDB considers any operation that takes longer than 100ms to be slow. If you see a trend of rising execution times, it's time to use the Query Profiler to investigate and identify the specific queries that are slowing things down.

3. Normalized CPU (System & Process)

CPU is a fundamental resource. In most monitoring tools, you'll see a "normalized" value, which is incredibly helpful. Normalization divides the absolute CPU usage by the number of CPU cores, giving you an easy-to-read percentage from 0-100%.

Normalized Process CPU: Tracks the CPU usage of the mongod process itself. This is your primary indicator of the database's CPU load.
Normalized System CPU: Tracks the total CPU usage of all processes on the host machine.

A healthy range for Normalized Process CPU is often between 40-70%.

Under 40%: You might be over-provisioned for your current workload.
Over 70% (sustained): You may be under-provisioned, and the CPU could become a bottleneck. When provisioning and sizing, CPU should always be considered alongside memory, storage, and IOPS.

4. Queues

The Queues metric shows the number of operations waiting for the database to process them. It's a direct measure of demand versus capacity.

Good: 0. When there are no queues, your database is keeping up with incoming requests.
Bad: Any sustained number greater than zero. A large queue indicates the database cannot process operations in a timely fashion, leading to increased latency for your application.

Queues are often a symptom of other problems, such as:

Inefficient queries that need indexes.
Hardware bottlenecks (CPU, IOPS).
Inefficient data models, such as many applications trying to update the very same document, causing lock contention.

Storage and Disk Metrics

5. Disk Space Percent Free

This one is straightforward: it's the percentage of your disk that is available. Monitoring the percentage is often more intuitive than tracking absolute gigabytes free, as it saves you a few mental steps.

Good: Consistently above 20%.
Caution: Falling below 10%. If available space is fully depleted, your database will stop accepting writes, leading to downtime. While 10% of a very large disk is still a lot of space, you may consider setting alerts for this.

6. Disk IOPS (I/O Operations Per Second)

This metric reflects the read and write throughput of your disk. It's crucial to ensure this value stays comfortably below the maximum IOPS provisioned for your hardware.

If the Disk IOPS metrics is consistently high, check the Disk Queue Depth metric - is it also showing a consistently high value (>10) as well? If yes to both, then you should consider increasing our provisioned IOPS or scaling up your cluster to get more RAM (when we can fit more data into our WiredTiger Cache, we will not need to go to the disk to retrieve data as often).

If your average IOPS is consistently hovering near the maximum, you are approaching a performance cliff. When disk IOPS are saturated, the storage subsystem cannot service read and write requests in a timely manner. This causes a cascading failure:

The database journaling system may block, waiting to write to disk.
The storage engine cannot flush modified data from memory to disk in a timely manner(checkpointing).
This leads to a surge in queue length and operation latency, causing the cluster to become unresponsive or stall.

To fix this, you can either provision more IOPS (which can be costly) or increase your storage size, as IOPS often scale with disk capacity on cloud providers.

Monitoring the Disk IOPS metrics is more important than the Max Disk IOPS metrics as it is the actual IOPS. Max Disk IOPS records the max IOPS observed and is not representative of your workload.

7. Disk Latency

This is the average time, in milliseconds, for read and write operations to complete on the disk. It's a direct measure of your storage performance.

Excellent: Consistently under 5ms.
Acceptable: Between 5ms and 20ms.
Bad: Sustained latency over 20ms signals a disk bottleneck. If you see latency spiking above 100ms, it's a critical issue that needs immediate investigation with your infrastructure provider.

Memory Related Metrics

MongoDB loves memory. It uses RAM to cache your working set (frequently accessed data and indexes), which dramatically reduces the need for slow disk I/O.

8. Memory (Resident vs. Virtual)

You'll typically see two memory metrics: virtual and resident. While virtual memory is the total address space allocated by the process, resident memory is the one to watch. It shows the actual amount of physical RAM the mongod process is using.

After your database has been running for a while and has loaded its working set into memory, the resident memory usage should stabilize into a relatively flat line. This indicates it has reached a steady state.

9. Cache Ratio (Fill & Dirty)

The WiredTiger storage engine uses an internal cache to hold data.

Cache Fill Ratio: This measures how full that cache is. In a healthy, active deployment, this value should hover around 80%. If your working set (the data you access frequently) fits in memory, this ratio will be high. If it approaches 100%, it could mean your working set is larger than your cache. Increasing the instance's RAM could reduce disk I/O and improve performance.
Dirty Fill Ratio: This represents the percentage of the cache that contains "dirty" data—data that has been modified in memory but not yet written (flushed) to disk. This value should stay below 5%. If it consistently goes above this, MongoDB may employ application threads to help with data eviction, directly degrading your database's performance.

10. Connections

Every open connection to your database consumes resources, typically around 1MB of RAM. It's vital to manage your connection pool effectively. Uncontrolled connections can exhaust RAM and bring a database to its knees.

For applications running in containerized environments like Kubernetes, where many pods can spin up, it's easy to create a connection storm. I typically recommend setting these two connection string options in your driver:

maxIdleTimeMS=60000: Closes connections that have been idle for 60 seconds, preventing unused connections from lingering.
maxPoolSize: Limits the number of connections per application instance. This setting is critical, but there's no single magic number—it truly depends on your application's workload and the infrastructure it runs on. For a microservice in a small pod (1-2 CPU cores), a conservative value like maxPoolSize=5 is an excellent starting point. However, if you have a monolithic application on a large 16-core VM, the default of 100 might be a perfectly reasonable choice to support the application's concurrency.

Your total connections can be estimated with:
Total Connections ≈ (Number of Application Pods) * maxPoolSize

Developer-Focused Metrics

These metrics provide direct feedback on the efficiency of your queries and data model.

11. Query Targeting

This is a powerful metric that measures index efficiency. It's the ratio of documents scanned to documents returned.

Query Targeting Ratio = documents examined OR index items examined / documents returned

Good: A ratio of 1:1 is perfect. This means your query / index was so effective that for every document MongoDB had to look at, it was a document your query needed.
Bad: A high ratio indicates your queries are scanning many irrelevant documents to find the ones they need. This points to missing or suboptimal indexes.

12. Scan and Order

This metric tracks queries that perform an in-memory sort. Sorting large result sets in memory after fetching them is very expensive, consuming significant CPU and memory.

Good: 0. This means all sorting is being done efficiently using an index's inherent order.
Bad: Any value greater than zero. If you see scanAndOrder operations, you should review your queries to see if a new or modified index can provide the requested sort order, eliminating the costly in-memory step.

Replication Metrics

For any production replica set, ensuring data is copied efficiently and reliably is paramount.

13. Replication Lag

This is the approximate time, in seconds, that a secondary member is behind the primary's write operations.

Good: Low and stable lag, typically under 5 seconds.
Bad: High (over 10 seconds) or growing lag. This can lead to stale reads from secondaries.

14. Replication Oplog Window

The oplog (operations log) is the special collection that records all write operations. The "oplog window" is the duration of time that those operations are retained. A sufficiently large window allows a secondary that falls behind (e.g., due to a network issue or downtime) to catch up without needing an "initial sync" — a highly resource-intensive process of re-copying the entire dataset.

We typically recommend customers maintain an oplog window of at least 3 days (72 hours). Why? Imagine a secondary stops replicating on a Friday evening. When the DBA comes in on Monday, they have a comfortable buffer to fix the node before it falls too far behind and requires a full resync.

15. Oplog GB/Hour

So, how do you size your oplog for a 3-day window? Use the Oplog GB/Hour metric. Find the amount of oplog data generated during your busiest hour and use that as a baseline.

Required Oplog Size = (Peak Oplog GB/Hour) * 72

Final Thoughts

Monitoring is not a passive activity. It's about understanding the story your database is telling you. By keeping an eye on these key metrics, you can move from a reactive to a proactive approach, ensuring your MongoDB deployment remains healthy, scalable, and performant.

What are your go-to metrics? Do you have other tips for interpreting database health? Share your thoughts and suggestions in the comments below!

(This article was inspired by and builds upon some concepts from MongoDB's monitoring guide.)

Integrating MongoDB Atlas Alerts with Lark Custom Bot via AWS Lambda

Hejun Wong — Sat, 21 Dec 2024 15:29:00 +0000

Why Integrate Atlas with Lark?

MongoDB Atlas provides a sophisticated monitoring system that can alert teams to performance issues, security concerns, or other critical system events. Lark, on the other hand, is a powerful, versatile communication platform gaining popularity among businesses for its efficient collaboration tools.

However, integrating these alerts with communication platforms like Lark can be challenging since Atlas doesn't directly support it. Integrating Atlas alerts with Lark can streamline incident management by ensuring that critical alerts are immediately communicated to the right team members through their preferred communication channels.

The Integration Strategy

Understanding the Workflow
To integrate Atlas alerts with Lark, we need to create a middleware that receives alerts from Atlas, transforms the data into a Lark-compatible format, and forwards it to Lark.

Here's a step-by-step overview of the process:

Setup a Lark Custom Bot in the Lark Group you would like to receive the Atlas Alerts
Set up an AWS Lambda Function: This function will serve as the middleware that processes incoming alert data from Atlas, transforms it into a format compatible with Lark and forwards it to the Lark group.
Configure API Gateway: Use API Gateway to expose a public REST endpoint that Atlas can send webhooks to. This gateway triggers the Lambda function.
Integrate Atlas with the Webhook: Configure your Atlas project to send alerts to the API Gateway endpoint.
Test out the Solution

Implementing the Solution

Define Environment Variables: Configure your Lambda function with the following environment variables to facilitate communication with Lark:

LARK_HOSTNAME: The base hostname for the Lark API. _open.larksuite.com_
LARK_PATH: The specific webhook path provided by Lark's Custom Bot /open-apis/bot/v2/hook/...
LARK_SECRET: The secret token provided by Lark's Custom Bot when signature verification has been enabled

AWS Lambda Function: Create a Lambda function that receives JSON payloads from Atlas and formats them for Lark.

import { request } from 'https';
import crypto from 'crypto';
function genSign(timestamp,secret) {
    // Take timestamp + "\n" + secret as the signature string
    const stringToSign = `${timestamp}\n${secret}`;
    // Use the HmacSHA256 algorithm to calculate the signature
    const hmac = crypto.createHmac('sha256', stringToSign);
    const signData = hmac.digest();
    // Return the Base64 encoded result
    return signData.toString('base64');
  }
export const handler = async (event) => {
    try {
        const parsedBody = JSON.parse(event.body);
        // Retrieve the humanReadable portion
        const humanReadableContent = parsedBody.humanReadable;
        const timestamp = Math.floor(Date.now() / 1000); // Example timestamp
        const secret = process.env.LARK_SECRET; // Replace with your Lark secret (enable Set signature verification)
        const signature = genSign(timestamp, secret);
        // Transform the payload to Lark's format
        const larkPayload = JSON.stringify({
            timestamp: timestamp,
            sign: signature,
            msg_type: 'text',
            content: {
                text: `Alert from MongoDB: \n${humanReadableContent}`,
            },
        });
        console.log('lark payload:', larkPayload);
        const options = {
            hostname: process.env.LARK_HOSTNAME, // Accesses the environment variable
            path: process.env.LARK_PATH,         // Accesses the environment variable
            method: 'POST',
            headers: {
                'Content-Type': 'application/json',
                'Content-Length': larkPayload.length,
            },
        };
        await new Promise((resolve, reject) => {
            const req = request(options, (res) => {
                let data = '';
                res.on('data', (chunk) => {
                    data += chunk;
                });
                res.on('end', () => {
                    if (res.statusCode === 200) {
                        resolve();
                    } else {
                        reject(new Error(`Request failed. Status code: ${res.statusCode}`));
                    }
                });
            });
            req.on('error', (e) => {
                reject(e);
            });
            // Write the larkPayload data
            req.write(larkPayload);
            req.end();
        });
        return {
            statusCode: 200,
            body: JSON.stringify({ message: 'Alert forwarded to Lark' }),
        };
    } catch (error) {
        console.error('Error sending alert to Lark:', error);
        return {
            statusCode: 500,
            body: JSON.stringify({ error: 'Failed to send alert to Lark' }),
        };
    }
}

AWS API Gateway: Configure it to trigger the above Lambda function when an REST request from Atlas is received.

Integrate Atlas with the Webhook

Within your MongoDB Atlas Project Settings Page
Navigate to the Integrations section
Configure a new "Webhook"
In the "Webhook" field, enter the API Gateway endpoint URL that you configured
Save the settings

Test out the Solution
Add the Webhook as a new notifier within an existing active alert (e.g. Host has restarted) and perform a Resiliency Test on your MongoDB Cluster

Conclusion

By creating this middleware, we've effectively integrated MongoDB Atlas alerts with Lark, enhancing the operational communication within your organization. This setup allows for immediate and streamlined alert management, ensuring that your team can respond quickly to any issues that arise. Feel free to adapt and expand upon this solution to suit your organization's specific needs.

Integrating Atlas alerts with Lark can be a simple yet powerful improvement to your operational workflow. I hope this guide helps you in implementing it. Let me know your thoughts and feel free to share any enhancements you make.

Load Testing MongoDB with Locust

Hejun Wong — Wed, 21 Aug 2024 15:43:23 +0000

What is Locust.io?

Locust is an open source load testing tool written in Python. Since it is written in Python, it is possible to containerise it and deploy it on Kubernetes.

Mongolocust allows you to code up MongoDB CRUD operations in Python and visualise their executions in a browser.

Why Load Test?

Load test helps us to understand how well our database performs under various levels of stress, identify performance bottlenecks and presents an opportunity to test our database's auto scaling capabilities.

Goals

In this article, you will learn how to deploy locust on AWS EKS and load test your MongoDB cluster.

Pre-requisites

Git installed on your local machine
AWS CLI installed on your local machine
AWS CLI Profile setup on your local machine, I named my profile "aws-tester"

Steps

Install kubectl, the Kubernetes CLI version of a swiss army knife

brew install kubectl

Install eksctl, a simple CLI tool for creating and managing clusters on AWS EKS

brew tap weaveworks/tap
brew install weaveworks/tap/eksctl

Create AWS EKS Cluster

eksctl --profile aws-tester create cluster \
--name mongo-locust-cluster \
--version 1.30 \
--region ap-southeast-1 \
--nodegroup-name locust-nodes \
--node-type t3.medium \
--nodes 2

Pull a copy of Mongolocust codes

git clone https://github.com/sabyadi/mongolocust.git

Set CLUSTER_URL within k8s/secret.yaml to your MongoDB Cluster's URL

cd mongolocust/k8s
vi secret.yaml

Deploy Mongolocust on AWS EKS

cd ..
./redeploy.sh

Forward 8089 port from master service to localhost

kubectl port-forward service/master 8089:8089

Access Locust Web Interface at (http://localhost:8089)

Scale Locust Workers

kubectl scale deployment locust-worker-deployment --replicas 10

Obtain Kubernetes nodes' IP addresses and whitelist on MongoDB Atlas

kubectl get nodes -o wide

Have fun load testing your MongoDB Cluster!

Implement a DevSecOps Pipeline with GitHub Actions

Hejun Wong — Sun, 16 Jun 2024 06:24:22 +0000

Introduction - Birth of DevSecOps

The story of DevSecOps follows the the story of Software Development closely. We saw how the industry moved from Waterfall to Agile and everything changed after Agile. With much shorter development cycles, there was also a need for faster deployments to production.

It was no longer feasible for Security teams to get the Dev / Ops teams to wait till Vulnerability Assessment and Penetration Testing (VAPT) was complete before changes could be pushed to production. If not, we nullify the advantage the team had with speed and agility.

DevOps is a set of practices intended to reduce the time between committing a change to a system and the change being placed into production, while ensuring high quality - Bass, Weber and Zhu

By definition, DevOps already includes Security as part of Operations but the Security industry wanted more focus and emphasis on Security hence the term DevSecOps or Secure DevOps came about.

Security Terms

Before diving into the implementation phase, let's familiarise ourselves with these 3 security terms.

SCA - stands for Software Composition Analysis. It is a technique used to find security vulnerabilities in third-party components that we use in our projects / products. They can be libraries, packages that we install.

We will be using Snyk (pronounced as "Sneak") for our SCA tool. Snyk is a developer-first SCA solution, helping developers find, prioritize and fix security vulnerabilities and license issues in open source dependencies

Create a free SNYK account at SNYK
Navigate to Account Settings
Generate Auth Token
This key would be your SNYK_TOKEN. Store it within your GitHub Actions Secrets.

SAST - stands for Static Application Security Testing. It is a technique used to analyse source codes, binary and byte codes for security vulnerabilities without running the code. Since the codes are not running but examined in static state, it is called static analysis. SAST, SCA and Linting are typical examples of static analysis

For SAST, we will be using Sonar. SonarCloud is a cloud based static analysis tool for your CI/CD pipeline. It supports dozens of popular languages, development frameworks and IaC platforms.

Create a free Sonar account at SonarCloud
Create a new Organisation and Project
Navigate to My Account, Security Tab
Generate a new Token
This token would be your SONAR_TOKEN. Store it within your GitHub Actions Secrets.

DAST - stands for Dynamic Application Security Testing. This is a technique used to analyse the running application for security vulnerabilities. Since the application is running and being examined dynamically, it is called dynamic analysis.

For DAST, we will be using OWASP ZAP. ZAP is the world’s most widely used web app scanner. It is a free, open-source penetration testing tool and at its core, ZAP is known as a “man-in-the-middle proxy”. You would find 3 Github actions belonging to OWASP ZAP within the GitHub Marketplace.

GitHub Actions

GitHub Actions is a CI/CD platform that allows us to automate our build, test and deployment pipeline

You can find it within your code repository on GitHub. It is the Actions Tab.

And when you click onto any of these workflow runs, you would be able to see the jobs that ran under that workflow

Above is a sample workflow.

Workflows are automated processes that you can configure to run one or more jobs. Workflows are defined by YAML files checked into your repository. These yaml files are stored in the .github/workflows directory. You can have multiple workflows, each of them doing a different set of tasks

The workflow can be triggered by an event (e.g. a pull request / when a developer pushes a change into the code repository)

When that happens, one or more jobs will start running.

Jobs are steps are executed in order and are dependent on each other. You can share data from one step to another as they are ran on the same runner.

Runners are servers that run your workflows when triggered and Github provides Linux, Windows and MacOS virtual machines for you to run your workflows.

Our Workflow

Our DevSecOps pipeline will consist of 3 jobs.

Build - requests for the latest ubuntu server, installs the latest github actions (v4), installs nodeJS version 20, installs our project's dependencies npm run install, runs our unit test npm run test and performs SAST using Sonar.

SCA - requests for the latest ubuntu server and for this job to start running, it needs the build job to be complete. It will install the latest github actions (v4) and runs Snyk against our code repository.

DAST - requests for latest ubuntu server, waits for SCA job to be complete, checks out the latest github actiosn (v4) and runs OWASP ZAP against a sample website (example.com).

The entire CICD pipeline can be implemented in just 50 lines of codes below.

name: Build code, run unit test, run SAST, SCA, DAST security scans for NodeJs App
on: push

jobs:
  Build:
    runs-on: ubuntu-latest
    name: Unit Test and SAST
    steps:
    - uses: actions/checkout@v4
    - uses: actions/setup-node@v4
      with:
        node-version: '20.x'
        cache: npm
    - name: Install dependencies
      run: npm install
    - name: Test and coverage
      run: npm run test
    - name: SonarCloud Scan
      uses: sonarsource/sonarcloud-github-action@master
      env:
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
      with:
        args: >
          -Dsonar.organization=[YOUR_SONAR_ORGANISATION]
          -Dsonar.projectKey=[YOUR_SONAR_PROJECT]
  SCA:
    runs-on: ubuntu-latest
    needs: Build
    name: SCA - SNYK
    steps:
      - uses: actions/checkout@v4
      - name: Run Snyk to check for vulnerabilities
        uses: snyk/actions/node@master
        continue-on-error: true
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
  DAST:
    runs-on: ubuntu-latest
    needs: SCA
    name: DAST - ZAP
    steps:
      - name: Checkout
        uses: actions/checkout@v4
        with:
          ref: main
      - name: ZAP Scan
        uses: zaproxy/action-baseline@v0.11.0
        with:
          target: 'http://example.com/'

Troubleshooting

You would notice that your unit test coverage report isn't being uploaded into SonarCloud. To fix this, create a sonar-project.properties file in the root of your repository. The file will inform Sonar where to retrieve your code coverage reports.

sonar.organization=[INPUT_YOUR_ORGANISATION]
sonar.projectKey=[INPUT_YOUR_PROJECT_KEY]

# relative paths to source directories. More details and properties are described
# in https://sonarcloud.io/documentation/project-administration/narrowing-the-focus/
sonar.sources=.
sonar.exclusions=**/tests/*.js
sonar.language=js

sonar.javascript.lcov.reportPaths=./coverage/lcov.info
sonar.testExecutionReportPaths=./test-report.xml

sonar.sourceEncoding=UTF-8

Resources

For a working example, you can refer to my repository

Cheers!

NodeJS Security Middlewares

Hejun Wong — Tue, 11 Jun 2024 15:20:59 +0000

Introduction

Many backend endpoints are written in NodeJS and it is crucial for us to protect our endpoints. A quick and simple way to do so would be to use middlewares.

Middleware

Middlewares allow us intercept and inspect requests, which makes it ideal for logging, authentication and inspecting requests. Here are 6 security middlewares which you can embed into your NodeJS project to secure it.

Helmet

The Helmet package sets security headers in our API responses. These headers provide important security-related instructions to the browser or client about how to handle the content and communication, thus helping to prevent various types of attacks.

CORS

The CORS package allows us to whitelist domains, controlling access to our web resources.

Express XSS Sanitizer

This package sanitizes user input data to prevent Cross Site Scripting (XSS) attacks

Express Rate Limit

If your Backend Servers are not fronted with a Web Application Firewall (WAF) or protected by DDoS mitigation services, you should definitely install this package to protect your endpoints from getting spammed by setting rate limits.

Express Mongo Sanitizer

This package sanitizes user-supplied data to prevent MongoDB Operator Injection.

HPP

As Express populates HTTP request parameters with the same name into an array, attackers may pollute the HTTP parameters to exploit this mechanism.

Sample Code on Usage

const express = require('express');
const app = express();

const cors = require("cors");
const helmet = require("helmet");
const { xss } = require("express-xss-sanitizer");
const rateLimit = require("express-rate-limit");
const hpp = require("hpp");
const mongoSanitize = require("express-mongo-sanitize");


// Rate limit 

// Trust the X-Forwarded-* headers
app.set("trust proxy", 2);

const IP_WHITELIST = (process.env.IP_WHITELIST || "").split(",");

const limiter = rateLimit({
  windowMs: 10 * 60 * 1000, // 10 mins
  max: 500, // Limit each IP to 500 requests per 10 mins
  standardHeaders: true, //Return rate limit info in the `RateLimit-*` headers
  legacyHeaders: false, // Disable the 'X-RateLimit-*' headers
  skip: (request, response) => IP_WHITELIST.includes(request.ip),
});

app.use(limiter);

//Sanitize data
app.use(mongoSanitize());

//Set security headers
app.use(helmet());

//Prevent XSS attacks
app.use(xss());

//Prevent http param pollution
app.use(hpp());

//CORS

const whitelist = ['http://localhost:4000']; 

const corsOptions = {
  origin: function (origin, callback) {
    if (whitelist.indexOf(origin) !== -1) {
      callback(null, true)
    } else {
      callback(new Error('Not allowed by CORS'))
    }
  }
}

app.use(cors(corsOptions));

How to write Better User Stories

Hejun Wong — Fri, 29 Jul 2022 04:18:00 +0000

User Stories

In Scrum, features are usually written in the form of User Stories.

There are 3 parts (the 3 Cs) to a User Story. Card, Conversations and Confirmations. However what's commonly missing are the set of Confirmations that should be appended to each user story.

The Card

User stories are typically written in this format:

As a [Administrator], I want the system to [allow me to administer user access], so that [I can approve and reject user access requests].

The Confirmations

Confirmations are written during the discussions between the Product Owner and the Dev Team. They are akin to a set of Acceptance Criteria.

Using the example above, we can create the following confirmations.

Email notification to be sent out to users holding onto the "Administrator" role whenever a new user request is submitted.
Only users holding onto the "Administrator" role can approve and reject users.
Email notification to be sent out to approved and rejected users.

With the set of confirmations, developers are now clearer on the requirements. There will be less ambiguity and we get closer to our ideal product at a faster rate.

Try it today🥳

Securing Windows Server 2019

Hejun Wong — Tue, 28 Jan 2020 13:31:58 +0000

This is my first blog post. I guess one of the best ways to learn fast, is by writing and sharing.

Today's post focuses on securing Windows Server 2019. I'm a developer, not a server guy but in my role, i'm exposed to the setup, configuration and patching of servers. To allow us to perform patching/maintenance as and when we like, we need a cluster of servers to achieve High Availability (HA). There are many ways to harden these servers and the method we have chosen is by enforcing group policies (GPOs) using the Domain Controller(s). Security policies are set centrally and propagated down to servers within the same domain.

The Center for Internet Security (CIS) publishes guidelines for securing both Windows and Linux servers. They are broadly categorized into Level 1 (L1) and Level 2 (L2). You can view L1 as baseline security and L2 as in-depth security where security is a must-have. There are thousands of policies which can be applied to help harden the servers. To do this efficiently, it is best to download the CIS-CAT scanner (there is a free "lite" version available!) and run it on your server. The scanner compares your server's configuration against the CIS Benchmarks.

With the scanning results, we can quickly decide to apply the necessary GPOs to reduce the number of attack surfaces. However, don't do this blindly. This may break your app. It is always about taking a prudent balance between functionality and security. Don't take unnecessary risks but going for a no-risk approach is no-go as well.

CIS has worked with the various cloud providers (AWS, Azure etc.) and users can now spin up pre-configured/CIS hardened VMs. This saves us huge amount of time and effort hardening the VMs, allowing us to sleep peacefully at night.

I'm new to this and would like to learn more about administering group policies efficiently. Are there templates available for download?