DEV Community: Victor Anuebunwa

Your application should be PCI-DSS-compliant

Victor Anuebunwa — Fri, 30 May 2025 00:38:54 +0000

If you’ve ever had to write an app to process card payments, not like integrating PayPal, but like being PayPal. You’ve probably heard of PCI DSS.

Payment Card Industry Data Security Standard (PCI DSS) is an information security standard for organizations that handle branded credit cards from the major card schemes. - Wikipedia

In other words, it’s a giant checklist that says: “Hey, if you’re going to store or process people’s money, maybe don’t leave your database open to the world.”

Why Am I Even Writing This?

After working on a PCI DSS–compliant app, I had a bit of an existential crisis and asked myself, “Why shouldn’t all apps follow PCI DSS secure coding practices?”

Believe me, PCI DSS is not as terrifying as it sounds. Compliance and privacy folks have a way of making every simple process sound enormous to feel good about themselves. Want to have a stressful day? Listen to them talk about PIA, DPIA, DSAR, or ROPA.

Not to oversimplify things, compliance can be painful. But if it helps protect your data and keeps you from ending up on “Have I Been Pwned”. Isn’t it kind of worth it?

Tips To Secure Coding

If you’re building a payment system or just trying to sleep better at night, here are some easy ways to secure coding that will bring you closer to PCI DSS compliance. Let’s dive in!

Subnets, NAT Gateways, and the Drama of Networking

If your app’s database is in a public subnet, I’m going to need you to stop reading and fix that. Now!

Ensure you use private subnets for anything sensitive, then route their traffic through a NAT Gateway so they can reach the internet (for patches, updates, memes, etc.) without being directly exposed. Think of it as giving your app a VPN to access the world, but telling it not to talk to strangers.

For “The Matrix” lovers, the Matrix world is a private subnet, the real world is the public subnet, and the secure phone Neo and his friends use to travel between worlds is the NAT Gateway. They can go through, but the machines can’t!

I love that reference, hope you do too. It took me a while. 😁

Encrypt All the Things

You’ve heard this before. You’ll hear it again.

Encrypt at rest.
Encrypt in transit.
Encrypt logs, backups, and even environment variables if you’re feeling spicy.

For cloud services, managing encryption is easy peasy. You only have to enable them.

And please, Base64 is not an encryption. It’s for people who lie to themselves. You know who you are. Sure, it has its uses, but security is not one of them.

Security Headers

Security headers are HTTP response headers that instruct the browser on how to handle security-related aspects of a website. They help you prevent attacks like Cross-Site Scripting (XSS), clickjacking, and man-in-the-middle attacks. Set It and Forget It

At the very least, add:

Strict-Transport-Security
X-Content-Type-Options
Content-Security-Policy
X-Frame-Options

They’re easy to configure in most frameworks and cloud services. Do it once, and you’re already better off than most.

Firewalls? Definitely Firewalls.

Route public requests to your application through a firewall. It’s like putting a bouncer in front of your app.

Unlike the days of the boomers, where configuring a firewall is like assembling your furniture with instructions from Asgard. You might get it working, but at what cost? Present-day applications make this process a lot easier. Better if you’re on the cloud.

Cloud services like AWS WAF and Azure Firewall already come with pre-configured rules for common threats; you just have to switch them on, and they get to work.

Firewalls with minimum effort will help you stop known attack patterns, filter out bad IPs, and block that one guy still trying SQL injection from 2008.

Access Control

Your app isn’t a public library. Don’t give every service full access to everything just because it’s easier. You’re not Oprah Winfrey: “You get admin! You get admin! Everyone gets admin!”

Follow the “Principle of least privilege”, which means every user gets only what they absolutely need.

Try to rotate credentials and keys regularly and use roles over static keys when possible. Even cloud services prefer this. And they wrote the cloud.

Staging Is Not Production

Your staging environment should mirror production in structure, not in secrets.

Encrypt staging data too. Attackers don’t care where they get data from.
Don’t copy production secrets into staging.
Implement monitoring and WAF rules here as well.

Hackers love a staging environment with fewer alarms. What’s a better place to test their scripts?

Change Management

This is adulting for DevOps. PCI DSS requires you to have procedures to track changes in code, infrastructure, and security policies.

In simple terms, use Git, use Infrastructure-as-code (Serverless Framework, Terraform, AWS CDK, etc.), and set up alerts. You want to know when someone (maybe even you) decides to push trauma into production.

Logging Saves Lives

Logs are crucial. You hope to never need them, but if you do, you really need them. Keep secure and central logs for everything that matters:

Application logs: Log errors from applications and other important information to help you debug. Make sure not to log sensitive information.
Access logs: Log who did what and when.
Database logs: Catch slow queries, weird access patterns, and potential breaches.
Audit logs: Log changes to permissions, firewall rules, and code deployments. Tools like AWS CloudTrail, GuardDuty, and Config can help you with this.

Prefer ORMs

This is your first line of defense (and sanity). Forget raw SQL unless you’re a database wizard with a death wish. Use an ORM. Yes, you could parameterize your raw SQL and improve security; however, there’s still a large chance that future you or your colleague will forget to parameterize a query properly, and just like that, you’re cooked.

ORMs abstract your database interactions, making code easier to maintain and less prone to injection attacks. Most modern ORMs parameterize queries out of the box. That means fewer chances to accidentally DROP TABLE users; during a late-night commit.

In Conclusion

Now, seriously, was it that deep? It’s a long list, but I’m sure it’s filled with things you’re already doing. Just a few adjustments here and there, and you’re compliant!

Compliance is annoying, but so is a data breach. PCI DSS might feel like a giant list of “No, you can’t” but it’s just trying to keep you and your customers safe. On cloud platforms like AWS, Azure, and GCP, there’s no excuse not to follow these best practices. You’ve got the tools, you’ve got the docs, and now you’ve got a very persuasive blog post.

Stay safe. Stay compliant. And for the love of all that is good, don’t store unencrypted card numbers in a database column called card_number.

AWS Lambda and RDS Connection Nightmare (How I Got Out)

Victor Anuebunwa — Wed, 21 May 2025 16:51:10 +0000

Some years back, I remember feeling fancy about my AWS Lambda and RDS setup until we had to process some large data from a CSV. In summary, it was a bad day. Database memory usage flew up, database connections flew up, my heart flew up, and the whole thing crashed in my face.

Yes, you can assume load testing was never invented.

It’s been a long time since then, and the issue is long gone. However, I still meet developers struggling with the same problem to this day, so I decided to share my experience and how we resolved it.

Context

My team needed to process data from CSV files periodically, which required extracting the data, computing the data, updating the database, and communicating with other services.

For extracting and computing, we used separate Lambdas and communicated via SQS/SNS.

For the database, we went with Aurora Serverless v1 because the processing was periodic. Or that’s what we want you to think. We are cheap people, and we’ll always go for the cheapest best option!

Aurora Serverless V1

Aurora Serverless is an AWS-managed database that scales on demand. It is normally more expensive than regular RDS with a heavy traffic load, but its ability to drop to zero during inactivity does magic. That means you don’t get to pay when the database is not in use.

Pros	Cons
Auto-scaling (eventually)	Cold start delays up to 30s
Can shut down when idle	Dropped transactions during cold boots
No instance to manage	Scaling latency under load

Why did it fail?

The major issue was the difference in scaling speed between AWS Lambda and RDS.

AWS Lambda is widely known for its scalability, and this is no joke. AWS Lambda functions scale horizontally in seconds, with each synchronously invoked function able to scale by 1,000 concurrent executions every 10 seconds.

Each new invocation may spin up a new environment (cold start) or reuse an existing environment (warm start). In most cases, connections are not shared across instances, and that means N invocations produce an equivalent of N environments, which produces N connections to the database.

Aurora Serverless can’t keep up. So they pile up and eventually, we hit the dreaded “Too many connections” error from the database.

Fixes We Attempted

Retry Mechanism

We added retries with exponential backoff. It helped… barely.

Connection Pooling (Don't Do It)

We tried connection pooling inside Lambda. Never worked. As explained earlier, new invocations create new environments, therefore, pools can’t be reused.

Leveraged Lambda Execution Freezing

Lambda tries to be helpful by freezing (sort of caching) the execution environment after a run. If Lambda is invoked again soon, AWS does a warm start, “thaws” the function, and reuses the environment.

Part of what is frozen by AWS are global variables. You can take advantage of this to reuse DB connections between invocations (if you’re lucky to get a warm start).

Don’t Do This

import os

def book_handler(event, context):
    db_url = os.getenv("DB_URL")
    db_client = db.connect(db_url)  # Opens a connection on every call
    book = db_client.get(book_id=event["book_id"])
    return book

Do This Instead

import os

db_url = os.getenv("DB_URL")
db_client = db.connect(db_url)  # Reused if Lambda stays warm

def book_handler(event, context):
    book = db_client.get(book_id=event["book_id"])
    return book

This minimizes connection churn and keeps the database happy. However, for large requests, this all means nothing.

Solution At Last

RDS Proxy

In late 2019, AWS announced RDS Proxy, and it became GA (General Availability) in mid-2020, and a game changer.

Amazon RDS Proxy is a fully managed database proxy for Amazon RDS. It acts as a connection pool between your application and the database, reducing the stress on database resources and improving application performance.

Why it’s your friend:

RDS Proxy provides lots of advantages that will help you sleep at night, these include:

Manages connection pooling for you
Works across multiple Lambda instances
Handles auth and failover
Reduces DB memory pressure

Caveats:

Adds a small latency (~few ms)
Not free, but worth it

Unfortunately, it doesn’t have support for older RDS engines, and this includes Aurora Serverless V1.

Aurora Serverless V2 to the Rescue

When Aurora Serverless V2 came out, things improved significantly.

It scaled faster than v1.
It had no cold start delay.
Still cost-effective for bursty traffic
And best of all, it had support for RDS Proxy!

TL;DR: The Golden Combo

Here’s the stack I now recommend, especially for periodic processing:

Lambda (use warm connections wisely)
Aurora Serverless V2
RDS Proxy
Retry logic with backoff
SNS/SQS for decoupling workloads

Final Thoughts

Using Lambda with RDS used to feel like mediating the US and China trade agreement, but with RDS Proxy and Aurora Serverless V2, the dream of serverless with relational DB is now actually viable.

That said, don’t blindly go all in. For long-running or batch-heavy DB jobs, sometimes containers or Fargate are a better fit, and DynamoDB (NoSQL) does a better job at scaling.

But if you’re sticking with Lambda (and I don’t blame you).

Just remember:

Don’t open DB connections inside the handler
Use Aurora Serverless V2 or DynamoDB
Prefer RDS Proxy for RDS
Load test your setup
And don’t trust blog posts too easily, especially this one. Test for your use case.

How we reduced our NodeJs app size on AWS Lambda by over 80% 😮

Victor Anuebunwa — Tue, 07 Sep 2021 08:58:03 +0000

This article highlights the steps we took to reduce the size of our NodeJs apps running on AWS Lambda but it still relates to any Node app running anywhere.
In the end, you'll find out how we dropped our 50MB - 75MB (compressed) node apps to 8MB - 10MB. Awesome, right?

But first, How did we get here?

How did this set of software developers exhaust the 75GB AWS Lambda storage limit?
Oh yes, we did. 🙈

The Mistake

Deploying microservices on AWS lambda could mean you have to work with other AWS services like SQS, SNS, API Gateway, etc., and using the Serverless Framework, the default practice will be to define handlers for events coming from each of these services.

Under the hood, the Serverless framework creates new lambda functions for each of the handlers you define.

Let's say you want to handle events from SNS, SQS, S3, and API Gateway, four Lambda functions will be created for each of those events using the same code base. This means that our 50MB app when deployed, becomes a huge 200MB app in total.

Here's the interesting part, this was only on our staging environment.
Considering the number of microservices we had running, we were already at 50% usage, pushing our microservices to a new environment immediately doubled our storage usage and our deployments broke. Wahala 🙆🏽‍♂️

The Fix: How we reduced our AWS lambda size

1. Set AWS-SDK as dev dependency

This is the mother of all. I won't even be bothered if you quit reading after this point.

The aws-sdk package alone is over 60MB (uncompressed). This is huge!

This was almost everything about our app size issue, our misfortune and also our miracle. The good news is that the aws-sdk comes pre-installed in your Lambda runtime, so you don't need to install it again. Only set it as a dev dependency.

Only if we knew this. I'm in severe pain now 😭

2. Remove unnecessary packages

There is a good chance you've done this already. However, for large projects mostly, some unused packages can go undetected easily.

Try packages like depcheck. It helps you scan your app for unused and missing dependencies.

npm install -g depcheck

The -g flag is important, please. Let's not complicate things here.

3. Cross-check for dev packages

Just like the aws-sdk, there are other packages that could disguise as production dependencies such as serverless and its plugins like serverless-offline.

These packages, in combination with the extra packages it installs for you, is over 100MB (uncompressed) in size, that is including aws-sdk. Hence, removing aws-sdk without removing these guys won't make any difference. It will be re-installed.

Since these types of packages are used for deployment and need to be installed while deployment is ongoing, one can easily mistake them as production packages.
The best approach will be to set them as dev dependencies in your app and install them globally in your CI/CD Docker image. This approach also buys you more deployment time as you won't need to reinstall them every time your CI/CD pipeline runs.

Created this Docker image avonnadozie/serverless for this purpose, feel free to reuse.
It comes with serverless-offline plugin and other necessary packages you need to deploy to lambda successfully.

4. Use `--production` flag

This should be a common step as well, however, It doesn't hurt to repeat it.

Always remember to use the --production when running npm on production or in your CI/CD script to not install dev dependencies.

npm install --production

5. Reuse available Lambda runtime packages

Just like aws-sdk, there are other packages such as uuid and dotenv that are already available in the lambda runtime which you can reuse.

You can refer to this list of node packages in lambda runtime.

6. Inspect deployment

The crude way works well too. Download your live code and inspect it manually.

To download, go to your Lambda console, click on the function and choose "Export function" from the "Actions" dropdown.

Then click on "Download deployment package" afterwards.

Once the download is complete, go to the node_modules folder, rank the folders by size and take a look. It reveals a lot.

This was how we found out aws-sdk was still installed even after we've set it as a dev dependency.

7. Move out large non-js files

Consider hosting large files such as images, or JSON on a private CDN (most likely S3) and read it from there.

This will cause a trade-off in speed but it could be worth it for you depending on the design of your app.

8. Merge serverless handlers

This is completely up to you and your app architecture, but you can consider reusing lambda functions where necessary to prevent serverless from creating additional and unnecessary functions for you.

For us, we found a way to merge SQS and SNS handlers given that their event input data and the way they work is similar and it saved us a whole lot of MBs.

The lambda console provides you with sample event input data on its test tab you can work with. Choose from the list.

Benefits to reducing your application size

You might not be deploying multiple apps that will exhaust your AWS limit as we did, but there's still more you stand to gain by dropping your app size regardless.

Faster cold start time
Faster deployment with CI/CD as the zipping and upload process will be faster
Less cost on storage and memory

How I survive testing on NodeJs and Jest 🤒

Victor Anuebunwa — Tue, 31 Aug 2021 15:57:28 +0000

Coming from a PHP background and with PHPUnit testing, I started my journey into writing tests on NodeJs with some expectations.

For most, I was disappointed but for some, I was blown away. I guess this is a feeling you have to get used to with JavaScript.

PHPUnit Vs Jest

PHPUnit provides you with more test functions to work with, has better error tracing, and is easier to debug.

However, testing on NodeJs is faster than testing with PHPUnit.

Correction, testing on NodeJs is way faster than testing with PHPUnit, because Jest runs your tests in parallel, and in the world of CI/CD, this means something very important. Fast deployment time! 🙌🏽

This is great, however, working with tests that run in parallel comes with its own challenges.

Tips for testing on NodeJs using Jest

Beware of asynchronous access to data

Tests running in parallel means that you will have multiple tests making requests to the database at the same time.

Expect inconsistency from tests like this

// Get User Test
 test('get user', async () => {
    const response = await request
      .get('/v1/user/1')
      .set('Authorization', `Bearer sample-token`)
      .send();

    expect(response.status).toBe(200);
 });

// Delete User Test
 test('delete user', async () => {
    const response = await request
      .delete('/v1/user/1')
      .set('Authorization', `Bearer sample-token`)
      .send();

    expect(response.status).toBe(200);
 });

The problem

The "Get user" test is going to be inconsistent depending on which of the tests runs first. If the "Delete User" test runs first, the "Get User" test will fail by the time it runs because the user will no longer exist.

The solution

Ensure that each test works with its own unique data.

// Get User Test
 test('get user', async () => {
    // Create a new user
    const user = User.create({name: "Sample user 1"});
   // Get the user
    const response = await request
      .get(`/v1/user/${user.id}`)
      .set('Authorization', `Bearer sample-token`)
      .send();

    expect(response.status).toBe(200);
 });

// Delete User Test
 test('delete user', async () => {
    // Create a new user
    const user = User.create({name: "Sample user 2"});
    // Delete the user
    const response = await request
      .delete(`/v1/user/${user.id}`)
      .set('Authorization', `Bearer sample-token`)
      .send();

    expect(response.status).toBe(200);
 });

Always remember your `Promises`

Always remember to await functions that return a promise.

Obvious right? I will bet you still forgot one some minutes ago.

On a serious note, these kinds of errors in tests can mess up your week and are difficult to detect. For example:

const user = User.findByPk(1); // no await
expect(user).not.toBeNull();

The problem

This will always be true as it will be testing on the returned Promise object which will not be null.

The solution

Await

const user = await User.findByPk(1); // await 
expect(user).not.toBeNull();

Prefer Debugger to `console.log`

Debugger adds more flare to error tracing, get used to it.

Debuggers allow you to literally go into the function and see what happens step by step and view the real content of each variable at any point, while console.log only shows you the string representation of the variable you log which could be hiding that extra piece of information you need to figure the bug out.

Additionally, console.log codes can easily find their way to production and you find yourself unknowingly logging sensitive information which could be dangerous.

Mock calls to external APIs or resources

This is more of a general tip when testing with any framework.

For most, your test should focus on testing the functions and features of your app, not the functionality or output of an external application.

Avoid consuming external resources during tests as this could introduce inconsistencies to your code when those requests fail and also increase the time your tests take to run.

It's best practice to mock these resources or API responses instead.

Example:

const getSignedUrl = (key, bucket = null) => {
  if (process.env.NODE_ENV === 'test') {
    return `https://s3.eu-west-2.amazonaws.com/sample/${key}`;
  }

  return s3.getSignedUrl('getObject', {
    Bucket: bucket,
    Key: key,
    Expires: 60,
  });
};

DEV Community: Victor Anuebunwa

Your application should be PCI-DSS-compliant

Why Am I Even Writing This?

Tips To Secure Coding

Subnets, NAT Gateways, and the Drama of Networking

Encrypt All the Things

Security Headers

Firewalls? Definitely Firewalls.

Access Control

Staging Is Not Production

Change Management

Logging Saves Lives

Prefer ORMs

In Conclusion

AWS Lambda and RDS Connection Nightmare (How I Got Out)

Context

Aurora Serverless V1

Why did it fail?

Fixes We Attempted

Solution At Last

RDS Proxy

Why it’s your friend:

Caveats:

Aurora Serverless V2 to the Rescue

TL;DR: The Golden Combo

Final Thoughts

How we reduced our NodeJs app size on AWS Lambda by over 80% 😮

The Mistake

The Fix: How we reduced our AWS lambda size

1. Set AWS-SDK as dev dependency

2. Remove unnecessary packages

3. Cross-check for dev packages

4. Use --production flag

5. Reuse available Lambda runtime packages

6. Inspect deployment

7. Move out large non-js files

8. Merge serverless handlers

Benefits to reducing your application size

How I survive testing on NodeJs and Jest 🤒

PHPUnit Vs Jest

Tips for testing on NodeJs using Jest

Beware of asynchronous access to data

The problem

The solution

Always remember your Promises

The problem

The solution

Prefer Debugger to console.log

Mock calls to external APIs or resources

4. Use `--production` flag

Always remember your `Promises`

Prefer Debugger to `console.log`