How To Dev

Introduction In previous articles, I have guided you through various ways to enhance project security through direct implementation. Now, I will demonstrate how to perform security audits for the packages you use. This is also a critical factor because while your codebase may be secure, a library you are using could contain hidden security risks that hackers can exploit. Detail First, let us look at how to check a package for security risks. Before installing, you can visit certain websites to verify package information, such as using https://security.snyk.io . This website provides comprehensive information to assess the health of a package and supports multiple languages. NPM Next is auditing security for the packages your project is currently using. Because technology changes rapidly, a package you use today might be fine, but it could reveal security risks a few months later. Therefore, this check needs to be performed regularly depending on the scale of the product you are develop...

Introduction Cross-Site Scripting (XSS) is a security vulnerability that allows attackers to inject malicious scripts, typically JavaScript, into web pages viewed by other users. When a user's browser executes this code, attackers can steal cookies, session tokens and alter the website interface. To prevent XSS, the following primary methods are used: Validation: Accepting only desired data formats. This simple approach only addresses surface-level issues, so we focus on the methods below for better effectiveness. Sanitization: Removing or disabling dangerous HTML tags and attributes such as <script> , onerror and onclick from user input before storage or display. Using Framework Automations: React and NextJS automatically escape data in text strings by default. When rendering HTML directly via dangerouslySetInnerHTML , using a library like DOMPurify is mandatory to ensure safety. Content Security Policy (CSP): Configuring browser policies to restrict script execution s...

Introduction In the previous article, I provided instructions on using NextJS Proxy to check API rate limits simply. However, that application method has the following scalability flaws: Using lru-cache only stores data in memory, so when scaling to multiple pods, the rate limit check will be incorrect because pods do not share data with each other. In actual deployment, you rarely let the NextJS server receive requests directly like that, but instead use additional CDNs (Cloudfront, Nginx) to take advantage of edge locations and their data caching capabilities. Therefore, in this article, I will provide a more comprehensive implementation from CDN, NextJS and NestJS servers to handle request spamming, including: Blacklist: automatically block IPs marked as attacking the system. Whitelist: add static IPs and only allow these IPs to use important services, such as allowing partner IPs to use services or deploying internal services accessible only via company VPN. Rate Limit: limit the n...