I’ve been developing a personal finance app focused on user budgeting and tracking spending habits in my spare time and one thing I’ve been concerned about is the protection of sensitive financial and user data.

Obviously, I’m going to build proper authentication and add thorough testing but I also needed a tool that could help me catch vulnerabilities within my application and possibly prevent malicious attacks. A lot of the data that gets passed around between external sources that users connect such as banks and wallets and within my app itself go through APIs that handle lots of sensitive data. So, my main concern was being able to somehow secure or protect these APIs. That’s why, today in this post, I want to share my experience using Metlo, a new API Security tool that has been helping me to solve the issues I am facing.

Discovering Metlo

I came across Metlo while I was searching for suitable security tools, and it appeared to have all the features I needed. Its capabilities included vulnerability detection in endpoints, attacker detection, and the ability to block malicious users. The setup process also seemed straightforward, and they had some quick setup docs for integrating with Node.js. Integrating Metlo into my app was pretty easy; I just added it to my project with yarn and then added a couple of lines for the configuration in the main server file as shown below and voila–it was up and running.

import { initExpress as metlo } from "metlo";

const app = express();
app.use(
  metlo(
    {
      key: <YOUR_METLO_API_KEY>,
      host: "https://app.metlo.com:8081",
    }
  )
);

Real-Time Traffic Monitoring

Once Metlo was properly configured, I was able to see all the traffic for my app on the dashboard. It showcased the various endpoints that existed within my application, along with the sensitive data they handled. I tried running some malicious requests with SQL Injection, RCE and XSS payloads and Metlo was able to identify me as a bad actor. It also displayed other useful information such as the distribution of status codes for my endpoints and what my top endpoints were.

Identifying and Blocking Attackers

What I found most useful was Metlo’s ability to detect and block attacks/attackers. I wanted to see how it would handle attack detection so I simulated sending a bunch of attacks from different IP addresses. I could view these attackers Metlo identified at the IP level and drill down to examine the requests and types of attacks that they were sending. I was then able to block them where Metlo would just return an error status code for requests made from that specific IP address. It also allowed me to customize the blocking, so that I could fine-tune the duration of the block. I could configure it to block attackers for a specific period of time, such as a few hours or even several days. I saw right away that it could identify specific types of attacks being sent in the request payloads, such as SQL injection (SQLi), Cross-Site Scripting (XSS) and Remote Code Execution (RCE).

I was also able to configure Metlo to identify my requests at the user level. Then, I was able to simulate the same attacks with different test users and it identified all the attacks by unique user, and I could also do the same blocking as before but now at the user level.

Additionally, I wanted to be able to monitor users who would be repeatedly trying to find vulnerable endpoints and block them. To do this, I was able to create my own detection rule in Metlo for flagging users who had too many requests which returned a 401, 403, 404, or 405 status code. I was able to easily test this out and saw this new detection being added to the event timeline.

WAF Rules

One aspect of Metlo that I initially glanced over but later found incredibly useful was its Web Application Firewall (WAF) rules feature. It allowed me to create custom rules for blocking or rate-limiting specific types of users. For instance, I was able to set up a rule to limit excessive requests made to my /login endpoint. If any user attempted more than 10 login requests within a minute, Metlo automatically blocked them for the next 10 minutes. I tested this out thoroughly with requests across different IP addresses and across different users and it was able to properly limit the requests for both. Also, in the Metlo UI, I was able to see which of my endpoints had high risk scores and handled sensitive data such as credit card numbers or addresses. Based on that, I also set up similar rate-limiting rules for these endpoints to prevent possible malicious activities targeting user data.

End-to-End Encryption

Another really important feature was that Metlo end-to-end encrypted any data that it captured from my app. I was able to generate a public-private keypair in the UI and it used that public key to fully encrypt any requests and responses it captured. Then using the private key, I could decrypt the data if I wanted to see the actual requests that were coming through. This was a dealbreaker for me because I didn’t want any of my users’ data being stored just plainly in a database somewhere.

Wrapping Up

So far, I’ve been using Metlo's protection features to initially test out its capabilities on my app, but there’s still a whole other Testing feature that it has that I'm starting to look into. Everything I’ve tried out has been pretty quick and easy so hopefully I can play around with the Testing more to help me catch any other authentication or authorization vulnerabilities that might exist in my app. If this is something that interests you, you can check it out at https://metlo.com .