As I have been working with OWASP Top 10, so far I have studied A01 to A04 and performed remediations according to them on my projects, so I can have an idea of security and standard testing of my web apps. In this article, I would like to tell you about my work regarding A05, which is Security Misconfiguration.
t is observed by me that many of the aspects addressed in one OWASP category can also be addressed in more than one category. So this is more about discipline while developing a web app.
In my work on OWASP A05, I performed the following remediations and improvements:
Note: As some aspects are also addressed in more than one OWASP category, my work is more likely inclined toward one specific category in this article.
Environment Configuration
One of the aspects that many beginner developers miss out on—and exhibit work-shyness in—is not preparing separate environments for:
- Development (Project Making)
- Local (Running on a local closed network)
- Production (Deploying the project as delivered and ready to meet the internet)
This configuration can be done by preparing .env files accordingly and editing them for the type of project start.
**For example: **It is best and advised to have this variable:
NODE_ENV=production
The variable value can be changed according to the project environment like "dev" for development, "local" for local, and "prod" for production.
This allows necessary condition checks and flag triggering such as:
if (process.env.NODE_ENV === "production") {
app.set("trust proxy", 1);
}
This allows IP address logging and other rate-limiting and security methods to be applied.
Note: Proxy must be trusted with this flag only if you are using NGINX or another trusted reverse proxy like Cloudflare or reputed hosting services.
Secure HTTP Headers
Another security misconfiguration that must be handled is the use of Helmet for securing HTTP headers.
import helmet from "helmet";
app.use(helmet());
This adds:
- Content-Security-Policy
- XSS Protection
- Frameguard
- HSTS
CORS Configuration
Another important configuration is CORS:
app.use(cors({
origin: ["https://yourfrontend.com"],
credentials: true
}));
One should regularly identify their domains and use the correct URLs in their CORS configuration.
Hide Sensitive Errors
Many developers forward backend errors to the frontend for quick debugging, like:
res.status(500).json({ error: err });
This is not advised, as it may expose backend structure, repositories, or system limitations.
Instead, use standard messages such as:
res.status(500).json({ message: "Internal Server Error" });
For debugging, use server logs:
try {
// Logic
} catch (error) {
console.error("Error While Processing In (Endpoint)", error);
res.status(500).json({ message: "Internal Server Error" });
}
Disable Stack Traces & Info Leaks
Information about backend resources matters a lot. It allows attackers to guess weaknesses and evaluate your servers.
We can use:
app.disable("x-powered-by");
This hides:
- X-Powered-By: Express
Enforce HTTPS
When using hosting services, they often handle HTTPS automatically.
But when deploying manually using a reverse proxy like NGINX, ensure:
- NGINX + Certbot setup
- Redirect HTTP → HTTPS
- Install SSL certificate
Usually, this is part of NGINX deployment.
Secure Cookies
While setting cookies from the backend, ensure the following:
res.cookie("token", token, {
httpOnly: true,
secure: true,
sameSite: "strict"
});
Remove Default Credentials
During development, many developers use default credentials for quick testing.
Removing these from the database is very important.
If missed, attackers might try:
- Username: admin
- Password: admin
and gain admin access.
Advanced Insight
Security Misconfiguration is NOT a bug. It’s a discipline problem.
Most developers:
- Focus on features
- Ignore deployment & configurations
Real engineers:
- Secure systems at both infrastructure and application levels