How broken authentication happens in Node.js Express APIs and how to fix it

The Incident: An Unprotected Blog API

In a Node.js Express application, we discovered a critical broken authentication vulnerability in api/routes/posts.js that left the entire posts API wide open. The POST endpoint at line 6 had no authentication whatsoever, while the PUT and DELETE endpoints used a username comparison that attackers could trivially bypass. This meant anyone on the internet could create posts, modify existing posts, or delete content—all without logging in.

The vulnerable code in api/routes/posts.js looked like this:

// CREATE POST
router.post("/", async (req, res) => {
    const newPost = new Post(req.body);
    try {
        const savedPost = await newPost.save();
        res.status(200).json(savedPost);
    } catch (err) {
        // res.status(500).json(err);
    }
});

Notice what's missing? There's no authentication middleware, no token verification, no check to see if the requester is even logged in. The endpoint blindly accepts req.body and saves it directly to the database.

The Vulnerability Explained

This vulnerability had three critical flaws working together:

Flaw #1: Zero Authentication on POST

The POST endpoint at router.post("/", async (req, res) => { had absolutely no authentication check. An attacker could send a request like this:

curl -X POST http://api.example.com/api/posts \
  -H "Content-Type: application/json" \
  -d '{
    "title": "Malicious Post",
    "content": "Spam content here",
    "username": "admin"
  }'

The server would happily create the post with whatever username the attacker specified. No password required. No token needed. Just pure, unauthenticated post creation.

Flaw #2: Client-Controlled Authorization Checks

The PUT and DELETE endpoints had authorization checks, but they were worse than useless—they created a false sense of security:

// UPDATE POST
router.put("/:id", async (req, res) => {
    try {
        const post = await Post.findById(req.params.id);
        if (post.username === req.body.username) {  // ⚠️ DANGEROUS
            // ... update the post
        }
    }
});

This code compares post.username (from the database) against req.body.username (from the attacker's request). An attacker could simply look up who wrote a post and include that username in their request:

# Step 1: Find a post by user "alice"
curl http://api.example.com/api/posts/123
# Response: { "id": "123", "username": "alice", "title": "Alice's Post" }

# Step 2: Delete it by claiming to be alice
curl -X DELETE http://api.example.com/api/posts/123 \
  -H "Content-Type: application/json" \
  -d '{"username": "alice"}'
# Success! Post deleted without any password or authentication.

Flaw #3: No Server-Side Token Verification

The code never calls any verifyToken middleware or checks JWT tokens. There's no req.user populated by authentication middleware, no session validation, nothing. The application trusts whatever the client sends in the request body.

Real-World Impact

For this blog application, the impact was severe:

• Content vandalism: Attackers could create spam posts as any user
• Data manipulation: Existing posts could be edited to spread misinformation
• Content deletion: Popular posts could be deleted to disrupt the platform
• Reputation damage: Posts created with forged usernames would appear legitimate
• No audit trail: Without proper authentication, there's no way to trace who actually made changes

The Fix: Database-Backed User Validation

The fix implements proper authentication by validating the userId against the actual User database before allowing any post operations. Here's the corrected POST endpoint:

Before:

router.post("/", async (req, res) => {
    const newPost = new Post(req.body);
    try {
        const savedPost = await newPost.save();
        res.status(200).json(savedPost);
    } catch (err) {
        // res.status(500).json(err);
    }
});

After:

router.post("/", async (req, res) => {
    try {
        const user = await User.findById(req.body.userId);
        if (!user) {
            return res.status(401).json("You are not authenticated!");
        }
        const newPost = new Post({ ...req.body, username: user.username });
        const savedPost = await newPost.save();
        res.status(200).json(savedPost);
    } catch (err) {
        res.status(500).json(err);
    }
});

Key Security Improvements

1. Database validation: The code now calls User.findById(req.body.userId) to verify the user exists in the database
2. Early return on failure: If no user is found, the endpoint returns 401 immediately
3. Server-side username assignment: Instead of trusting req.body.username, the code uses user.username from the verified database record
4. Proper error handling: The commented-out error handler is now active

The PUT and DELETE endpoints received similar fixes:

Before (PUT):

const post = await Post.findById(req.params.id);
if (post.username === req.body.username) {  // ⚠️ Client-controlled
    // ... update logic
}

After (PUT):

const user = await User.findById(req.body.userId);
if (!user) {
    return res.status(401).json("You are not authenticated!");
}
const post = await Post.findById(req.params.id);
if (post.username === user.username) {  // ✅ Server-verified
    // ... update logic
}

Now the authorization check compares post.username against user.username from the database lookup, not from the client's request body. An attacker can't forge this because they'd need a valid userId that actually exists in the User table.

Why This Fix Works

The fix transforms the security model from "trust the client" to "verify on the server":

1. Database as source of truth: Every request must reference a real user ID that exists in the database
2. No client-controlled authorization: The username comes from the User model, not from req.body
3. Fail-safe defaults: If the user lookup fails, the request is rejected before any database writes

However, this is still an incomplete fix for production. The code validates that a userId exists but doesn't verify that the requester actually is that user. A complete solution would:

• Add JWT middleware to verify tokens and populate req.user
• Compare req.user.id (from the verified token) against the user ID
• Remove userId from the request body entirely—it should come from the authenticated session

Key Takeaways

• The POST /api/posts endpoint had zero authentication, allowing anyone to create posts without logging in
• Client-controlled username comparisons are not authorization—attackers simply include the target username in their request body to bypass checks
• Always validate userId against your User database before processing requests, but this alone isn't sufficient
• Complete authentication requires JWT middleware or session verification to prove the requester actually owns the userId they're claiming
• Never trust req.body for identity information—always use server-verified tokens or sessions to populate req.user

How Orbis AppSec Detected This

• Source: HTTP request body parameters (req.body.username, req.body in POST endpoint)
• Sink: Database write operations (newPost.save(), Post.findByIdAndUpdate()) in api/routes/posts.js:6, :29, :58
• Missing control: No authentication middleware (verifyToken) before route handlers; authorization checks compared client-provided username instead of server-verified user identity
• CWE: CWE-287 (Improper Authentication) and CWE-306 (Missing Authentication for Critical Function)
• Fix: Added User.findById() validation to verify userId exists in database before processing post operations

Orbis AppSec automatically detected this vulnerability and opened a pull request with the fix. Try Orbis AppSec on your repositories to find and fix issues like this automatically.

Conclusion

This broken authentication vulnerability in api/routes/posts.js demonstrates why authentication must be handled server-side with verified tokens or sessions—never by trusting client-provided usernames or IDs. The fix adds database validation to ensure the userId exists, but production applications should go further by implementing proper JWT middleware that verifies tokens and populates req.user with authenticated identity. By following the principle of "verify, don't trust," and using established authentication patterns, you can prevent attackers from impersonating users and accessing resources they shouldn't control.