DEV Community

Cover image for OWASP Top 10 – A05: Security Misconfiguration (Remediation Perspective)
Hassam Fathe Muhammad
Hassam Fathe Muhammad

Posted on

OWASP Top 10 – A05: Security Misconfiguration (Remediation Perspective)

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

Enter fullscreen mode Exit fullscreen mode

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);
}
Enter fullscreen mode Exit fullscreen mode

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());
Enter fullscreen mode Exit fullscreen mode

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
}));
Enter fullscreen mode Exit fullscreen mode

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 });

Enter fullscreen mode Exit fullscreen mode

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" });

Enter fullscreen mode Exit fullscreen mode

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" });
}
Enter fullscreen mode Exit fullscreen mode

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");

Enter fullscreen mode Exit fullscreen mode

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"
});

Enter fullscreen mode Exit fullscreen mode

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

Top comments (0)