Category: education

Checklist for Securing Your API – Lessons from my own scars

API Security Scorecard

TLDR:  Try the Interactive API Security Checklist

 

“How I Learned to Stop Worrying and Love Security Checklists”

because I loved Dr Strangelove

 

After years of building APIs (both inside and outside) AWS and watching them get pwned in creative ways, I’ve learned one harsh truth: your API security is only as good as your worst oversight.

Remember that time you forgot to validate file uploads and someone uploaded a 500GB “image”? Or when you trusted user input and got a lovely SQL injection for Christmas? Yeah, me too. 🎄💀

The Problem with API Security

Devs often approach API security like this:

  1. “Let’s add some input validation”
  2. “HTTPS should be enough, right?”
  3. Gets hacked
  4. “Oh.”

I’ve been there. We all have. The issue isn’t that we don’t care about security—it’s that security is boring and easy to forget. You’re focused on making your endpoints work, not on the 47 different ways they can be exploited.

Enter: The Interactive Security Scorecard

So I built this: Interactive API Security Checklist

It’s basically a gamified security audit. You check off what you’ve implemented, mark irrelevant items as “N/A” (because not every API needs file upload security), and watch your security score climb toward 100%.

Key features:

  • 86 security checks across 9 categories
  • Smart scoring that ignores N/A items
  • “Select All” for when you’re feeling confident
  • Export your progress (for those compliance meetings)

Why This Actually Works

Unlike those 200-page security documents that make you want to switch careers, this checklist:

  • Fits your workflow: Check items as you implement them
  • Covers the basics: Input validation, headers, rate limiting—the stuff that stops 90% of attacks
  • Admits reality: Some checks don’t apply to your API, and that’s fine

My Reality Check

Working with large-scale, complex systems and years spent with Red/Blue team taught me that security isn’t about being perfect—it’s about not being the lowest-hanging fruit. Most attacks succeed because of basic oversights: missing rate limits, unescaped output, or trusting Content-Type headers.

This checklist covers those “wait, I was supposed to do WHAT?” moments that happen at 2 AM when your API is getting hammered by bots.

The Bottom Line

Security doesn’t have to be overwhelming. Start with the basics, use tools that make it easier, and stop pretending you’ll remember everything without a checklist.

Your future self (and your incident response team) will thank you.


Pro tip: Bookmark the checklist and run through it before every deployment. It takes 10 minutes and beats explaining to your manager why the API is down because someone figured out your error messages leak database schemas.

→ Try the Interactive API Security Checklist

From F to A+

TL;DR: this post is about how I improved my site ssllab.com HTTPS rating from F to A+ .


Make HTTPS great again.

Not all HTTPS-enabled sites are created equally, so welcome to the Internet of broken protocols and pardon my usage of a political phrase.

When I set up this site long ago, it was running on VPCs with many components which with today’s standards, were considered vulnerable: OpenSSL 1.1.0g, PHP5.4, Apache2.1 on Debian 7. You named it.

That’s why ssllabs.com used to rate my site as F:

Before

file

After

It’s rated A+, and I’m pretty proud of it.

file

How?

Here are the detailed steps on how I improve my site security from F to A+ in few simple steps.

1. First thing first: bye-bye to outdated OpenSSL

The previous version of openssl on Debian was suffering from these 2 critical vulnerabilities: SSL Pulse (CVE-2014-0224) & Padding Oracle (CVE-2016-2107). That’s the reason why SSLLab report an F.

The fix was fairly simple: upgrading OpenSSL.

sudo apt update && sudo apt upgrade openssl libssl-dev

After that, check the version:

openssl version
OpenSSL 1.1.1d  10 Sep 2019

2. No more outdated ciphers

SSLLabs also reported another two issues which cap the grade at B:

  • “This server accepts RC4 cipher, but only with older protocols. Grade capped to B”
  • “This server does not support Forward Secrecy with the reference browsers. Grade capped to B.”

Ok, onto finding Apache2 config files:

# assuming Apache2 is at /etc/apache2 
grep -i -r "SSLEngine" /etc/apache2
/etc/apache2/sites-available/default-ssl.conf:   SSLEngine on
/etc/apache2/sites-available/diophung.com.conf:  SSLEngine on

Here we go, the config files are default-ssl.conf and diophung.com.conf. From there, I decided to remove RC4 due to its flaws, and then enable Forward Secrecy in the config files:

SSLProtocol all -SSLv2 -SSLv3
SSLHonorCipherOrder on
SSLCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS !RC4"

After that, restart Apache2 and recheck

apachectl -k restart

3. Why stop at A when you can get A+?

At this step, ssllabs rated the site as A, which is pretty good result. But I figured I can get to even better result A+ and being me, I wouldn’t stop. So the next step, is to enable HSTS:

I opened up the Apache2 config files and add this HSTS header:

<VirtualHost diophung.com:443>
Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains; preload"
</VirtualHost>

Feel free to read up about HSTS if you’re curious.

Voila!

After everything, the site is now rated as an A+ result. I’m pretty happy about it and a bonus is that the site also loads 45% faster. So, strongly recommend you give it a try: https://ssllabs.com and let me know what score do you have?