API and API Design: API Security (part 2)

Sponsored by

Hello “👋

Welcome to another week, another opportunity to become a Great Backend Engineer.

Today’s issue is brought to you by Masteringbackend → A great resource for backend engineers. Learn backend development practically.

Still stuck in tutorial hell?

We’ve all been there—jumping from one Python video to the next, but never building anything real.
No portfolio. No confidence. No callbacks.

That’s why I created this.

The “Land Your Dream Python Job” Challenge
A 90-day, 3-phase roadmap that helps you:

✅ Build 30 real-world backend projects in 30 days
✅ Master DSA for technical interviews
✅ Get job-ready with resumes, mock interviews & daily job alerts
✅ And finally... land that backend job

This is NOT another course. It’s a challenge. And it works.

Over 2,000 Python developers have taken this path—many are now working at top companies.

Only 120 slots left at $54 (then goes up to $100)

Join the challenge & change your future
👉 python30.masteringbackend.com

Let’s get you unstuck.

Looking for unbiased, fact-based news? Join 1440 today.

Join over 4 million Americans who start their day with 1440 – your daily digest for unbiased, fact-centric news. From politics to sports, we cover it all by analyzing over 100 sources. Our concise, 5-minute read lands in your inbox each morning at no cost. Experience news without the noise; let 1440 help you make up your own mind. Sign up now and invite your friends and family to be part of the informed.

Subscribe to 1440 today.

Welcome to another episode of Backend Weekly, previously, I covered the top 4 security risks from OWASP Top 10, and in this issue, I will continue with API Security and cover the remaining 6 API security tips from the OWASP 10 list below:

✅ Broken Authentication
✅ Broken Object Level Authorization
✅ Broken Object Property Level Authorization
✅ Unrestricted Resource Consumption

Next, I will cover the following:

• Broken Function Level Authorization

• Unrestricted Access to Sensitive Business Flows

• Server-Side Request Forgery

• Security Misconfiguration

• Improper Inventory Management

• Unsafe Consumption of APIs

Broken Function Level Authorization

This issue is listed in the OWASP API Security Top 10 as API5 – Broken Function Level Authorization.

It occurs when APIs expose endpoints that don’t properly check whether the authenticated user has permission to access the function being called.

Complex access control policies—such as those involving user roles, groups, and permissions—can lead to improper checks or lack of authorization logic altogether.

Example:

Below is an example that covers the broken function level authorization security bridge and some of the possible solutions. Suppose an API has both regular users and admin users, but it fails to enforce role-based authorization:

// INSECURE: No role check — anyone can access admin route
app.delete('/admin/delete-user/:id', async (req, res) => {
  await db.User.deleteOne({ _id: req.params.id });
  res.send('User deleted');
});

Solution:

Implement middleware to enforce role-based access control (RBAC):

function requireAdmin(req, res, next) {
  if (req.user.role !== 'admin') {
    return res.status(403).send('Access denied');
  }
  next();
}

app.delete('/admin/delete-user/:id', requireAdmin, async (req, res) => {
  await db.User.deleteOne({ _id: req.params.id });
  res.send('User deleted');
});

Additionally, ensure that roles are properly validated during login and token creation:

const token = jwt.sign({ id: user.id, role: user.role }, process.env.JWT_SECRET);

By adding a clear separation of duties and verifying access based on user role or group, APIs can better prevent unauthorized access to sensitive operations.

Unrestricted Access to Sensitive Business Flows

This vulnerability is defined in the OWASP API Security Top 10 (2023) as API6 – Unrestricted Access to Sensitive Business Flows. It arises not from code bugs, but from a lack of strategic business rule enforcement.

APIs may expose critical operations—like purchasing items, creating accounts, or submitting comments—without considering how these operations could be abused at scale. This allows attackers or bots to overwhelm business services in ways that hurt revenue, credibility, or functionality.

Example:

Suppose you have an endpoint that allows users to post comments on a product:

// INSECURE: No user limits, abuse protection, or flow control
app.post('/products/:id/comment', async (req, res) => {
  const { comment } = req.body;
  const { id } = req.params;
  await db.Comment.create({ productId: id, userId: req.user.id, text: comment });
  res.send('Comment added');
});

A spam bot could hit this endpoint thousands of times, flooding your app with spam and damaging trust with legitimate users.

Solution:

Introduce safeguards including:

• Rate limiting to restrict frequency.

• Behavioral analysis to detect bots.

• Business logic rules to cap use (e.g., one comment per user per 10 minutes).

const rateLimit = require('express-rate-limit');

const commentLimiter = rateLimit({
  windowMs: 10 * 60 * 1000, // 10 minutes
  max: 3, // Max 3 comments per window
  message: 'Commenting too frequently. Please slow down.'
});

app.post('/products/:id/comment', commentLimiter, async (req, res) => {
  const { comment } = req.body;
  const { id } = req.params;

  const recent = await db.Comment.find({
    productId: id,
    userId: req.user.id,
    createdAt: { $gte: new Date(Date.now() - 10 * 60 * 1000) }
  });

  if (recent.length >= 1) {
    return res.status(429).send('You can only comment once every 10 minutes.');
  }

  await db.Comment.create({ productId: id, userId: req.user.id, text: comment });
  res.send('Comment added');
});

This ensures sensitive flows are governed by rate and relevance, reducing the risk of economic abuse or reputational harm.

Server-Side Request Forgery

This vulnerability is listed under OWASP API Security Top 10: API7 – Server Side Request Forgery.

SSRF vulnerabilities occur when an API endpoint allows users to specify URLs or IP addresses to fetch remote resources, but the server does not adequately validate these inputs.

Attackers exploit this to make the server issue requests to internal systems, cloud metadata endpoints, or other protected environments.

Example:

Here's an example of a vulnerable Node.js/Express endpoint that accepts a URL as input:

// INSECURE: No input validation, direct use of user-supplied URL
const axios = require('axios');

app.get('/proxy', async (req, res) => {
  const { url } = req.query;
  try {
    const response = await axios.get(url);
    res.send(response.data);
  } catch (err) {
    res.status(500).send('Error fetching resource');
  }
});

With this implementation, a malicious actor can make the server request internal URLs such as:

GET /proxy?url=http://localhost:8000/admin
GET /proxy?url=http://169.254.169.254/latest/meta-data/  // AWS metadata

This can lead to data exfiltration or allow attackers to bypass firewall protections.

Solution:

1. Implement input validation to allow only approved domains.

2. Use allowlists to define safe URLs or domains.

3. Disallow local IPs like 127.0.0.1, 169.254.x.x, and internal ranges.

const dns = require('dns');
const isValidUrl = require('valid-url');

app.get('/proxy', async (req, res) => {
  const { url } = req.query;

  if (!isValidUrl.isUri(url)) {
    return res.status(400).send('Invalid URL');
  }

  const parsedUrl = new URL(url);
  const hostname = parsedUrl.hostname;

  // Only allow requests to a predefined list of domains
  const allowedHosts = ['example.com', 'api.trusted.com'];
  if (!allowedHosts.includes(hostname)) {
    return res.status(403).send('Access denied');
  }

  try {
    const response = await axios.get(url);
    res.send(response.data);
  } catch (err) {
    res.status(500).send('Error fetching resource');
  }
});

In highly sensitive applications, use an external proxy layer to isolate request fetching from your API server entirely.

APIs are essential to the architecture of modern software systems, but they also introduce new security risks. API security must be integrated from the earliest stages of design and remain a continuous practice throughout development and operation.

As APIs grow in number and complexity, so do the threats. Prioritize security, implement best practices, and choose the right tools to safeguard your API ecosystem.

Did you learn any new things from this newsletter this week? Please reply to this email and let me know. Feedback like this encourages me to keep going.

Remember to start learning backend engineering from our courses:

Get a 50% discount on any of these courses. Reach out to me (Reply to this mail)

1. Become a Node.js Backend Engineer is Live

2. Become a Rust Backend Engineer is Live

3. Become a Python Backend Engineer is Live

4. Become a Java + Spring Backend Engineer is Live

Backend Engineering Resources

1. Backend Engineering Hub

2. All Backend Books

3. Visit our Backend Store

4. Join our Community

5. Backend Engineering Courses

LAST WORD 👋 

How am I doing?

I love hearing from readers, and I'm always looking for feedback. How am I doing with The Backend Weekly? Is there anything you'd like to see more or less of? Which aspects of the newsletter do you enjoy the most?

Hit reply and say hello - I'd love to hear from you!

Stay awesome,
Solomon

I moved my newsletter from Substack to Beehiiv, and it's been an amazing journey. Start yours here.