If you’ve built an API with Node.js, chances are you’ve thought about security – at least a little. Maybe you’ve heard about SQL injection, brute force attacks, or data leaks. But here’s the thing: it’s not just about big hacks. Even small gaps in yo...

freeCodeCamp is a nonprofit organization offering free online coding courses and programming tutorials, covering topics such as web development, data science, and machine learning. Learners can gain practical coding skills, build real-world projects, and earn certifications to advance their careers in tech.

freeCodeCamp

Learn how to enhance the security of your Node.js APIs with practical tips focusing on using environment variables, input validation, rate limiting, enforcing HTTPS, securing HTTP headers with Helmet, data sanitization, and strong authentication and authorization methods. These measures aim to protect against SQL injection, brute force attacks, and data leaks, among other threats.

How to Harden Your Node.js APIs – Security Best Practices

6. Sanitize Data to Prevent Injection Attacks

7. Use Strong Authentication and Authorisation

Personally, I wouldn’t recommend rate limiting every endpoint or API across the board. Tools like Cloudflare, Akamai, and others are specifically built to handle that kind of protection at the edge. Instead of restricting legitimate clients, who may have valid use cases like bulk processing or fetching data with many concurrent requests, we should focus on limiting malicious traffic. And that kind of filtering is often better handled outside your application code using the infrastructure tools mentioned above.

Personally I wouldn’t recommend so many external packages in your code since it increase external dependencies a lot which is sometimes not good for the app performance

I suggest coding an application focus on the business problem to be solved, and use proper ‘wrapper’ services depending on your budget and hosting maturity implement security outside of that business logic. (high&gt;low hosting maturity - API gateway, NGINX Reverse proxy, Express Server).

xxs-clean (<a href="https://www.npmjs.com/package/xss-clean" target="_blank" rel="noopener nofollow">https://www.npmjs.com/package/xss-clean</a>) is deprecated

Not sure about using <code>.env</code> files for things like db passwords.
The little AI blurb I got when googling if dotenv is safe in prod:
<blockquote>
“Using dotenv in production is generally not recommended due to &gt; security risks. .env files are stored in plain text and can be exposed if &gt; not properly managed, leading to potential unauthorized access to &gt; sensitive information”
</blockquote>
Dotenv is great for doing dev/prod specific things like in dev you may have some mock/dev APIs to call rather than your prod ones and you can use an env variable to check which environment the server is running on to determine the API to call for example