A Reddit post about ‘hacking’ a pharmacy highlights a terrifyingly common API vulnerability that keeps engineers like me up at night. Here’s a breakdown of the root cause and three levels of fixes, from a 3 AM patch to a full architectural shift.

When API Endpoints Become Open Invitations: A Post-Mortem on ‘Hacking’ a Pharmacy

I remember a PagerDuty alert that went off around 2 AM. It wasn’t the usual ‘prod-db-01 is down’ or a CPU spike. It was a high-priority ticket from our security team with a single link to a Reddit thread. The title was something like, “How I got free stuff from [Our Company Name] by changing a number in the URL.” My blood ran cold. It’s that sinking feeling every engineer dreads—the realization that a simple oversight, a moment of “we’ll fix it later,” has just become a five-alarm fire. The story about hacking a pharmacy for free prescriptions hit me the same way. It’s not sophisticated black-hat wizardry; it’s a symptom of a deep, fundamental mistake we sometimes make: we trust the client.

The “Why”: Trusting the Untrustworthy

The root cause of this kind of “hack” is almost always an Insecure Direct Object Reference (IDOR). It’s a fancy term for a very simple problem. Let’s say you, as a logged-in user, request your prescription history via an API call:

GET /api/v1/prescriptions?user_id=12345

The server sees this, fetches all prescriptions for user 12345 from the database, and sends them back. The problem? The server never asked the most important question: “Is the person making this request actually user 12345?”

The “hacker” in the Reddit thread simply changed that ID. They sent a request like:

GET /api/v1/prescriptions?user_id=12346

And because the backend was built on this flawed foundation of trust, it happily served up someone else’s private data. The authentication was there—the user had to log in. But the authorization—the check to see if that authenticated user had permission to access that specific data—was completely missing.

The Fixes: From Duct Tape to Fort Knox

So, you’ve just been woken up by that security alert. The vulnerability is live on `prod-api-gateway-01`. What do you do? Here are the options, from the immediate firefight to the long-term architectural solution.

Solution 1: The Quick Fix (The “3 AM Bleeding Stopper”)

Your immediate goal is to stop the data leak. You don’t have time to refactor the entire auth system. You need a targeted, surgical strike. This usually involves adding a specific check directly in the vulnerable controller or route handler.

Let’s say your code for that endpoint looks something like this (pseudo-code):

function getPrescriptions(request) {
  // OOPS: trusts the user_id from the query string
  const userId = request.query.user_id; 
  const data = database.find('prescriptions', { owner: userId });
  return response.json(data);
}

The quick fix is to jam an authorization check right in there. You get the ID of the *logged-in user* (from their session or JWT) and compare it against the ID they are requesting.

function getPrescriptions(request) {
  // Get the authenticated user's ID from the token/session
  const authenticatedUserId = request.user.id; 
  const requestedUserId = request.query.user_id;

  // THE FIX: Check for ownership
  if (authenticatedUserId !== requestedUserId) {
    // Log this attempt and return a generic error!
    log.warn(`SECURITY: User ${authenticatedUserId} tried to access data for ${requestedUserId}`);
    return response.status(403).json({ error: "Forbidden" });
  }

  const data = database.find('prescriptions', { owner: requestedUserId });
  return response.json(data);
}

This is hacky. It puts authorization logic in your business logic. It’s technical debt. But it stops the bleeding in five minutes, and sometimes, that’s what matters most.

Solution 2: The Permanent Fix (The “Do It Right” Approach)

Once the fire is out, you need to fix the underlying problem. A single vulnerable endpoint usually means there are others. The “right” way is to enforce authorization at a higher level, typically with middleware that runs on every protected API route.

The principle is simple: every piece of data in your system that has an “owner” should be checked against the authenticated user. This middleware intercepts the request before it ever hits your main logic.

// Centralized Authorization Middleware
function checkOwnership(resourceType) {
  return async function(request, response, next) {
    const authenticatedUserId = request.user.id; // From JWT
    const resourceId = request.params.id; // e.g., /prescriptions/:id

    const resource = await database.find(resourceType, { id: resourceId });

    if (!resource || resource.ownerId !== authenticatedUserId) {
      log.warn(`AUTHZ_FAIL: User ${authenticatedUserId} failed ownership check for ${resourceType}:${resourceId}`);
      return response.status(403).json({ error: "Forbidden" });
    }

    // If check passes, continue to the actual route handler
    next(); 
  }
}

// Applying the middleware to a route
app.get('/api/v1/prescriptions/:id', checkOwnership('prescriptions'), getSinglePrescription);
app.get('/api/v1/appointments/:id', checkOwnership('appointments'), getSingleAppointment);

This approach centralizes your authorization logic. It’s clean, reusable, and makes your actual business logic dumber and safer. You are building a secure-by-default pattern instead of playing whack-a-mole with vulnerabilities.

Pro Tip: When you implement these checks, make sure your logging is on point. A failed authorization check shouldn’t just return a 403 Forbidden; it should trigger a high-severity alert in your monitoring system. You want to know immediately if someone is rattling the doorknobs.

Solution 3: The ‘Nuclear’ Option (The Zero Trust Overhaul)

Sometimes, the problem is so deeply embedded in a legacy monolith or a tangled web of microservices that fixing it in the application layer is a nightmare. In these cases, or for new projects, you can go a step further and enforce policy at the infrastructure level. This is the core idea of a Zero Trust Architecture.

Instead of the application being responsible for security, you use a service mesh (like Istio or Linkerd) or an API Gateway (like Kong or Traefik) to intercept all traffic and make authorization decisions based on policies you define.

For example, with Istio, you can write an `AuthorizationPolicy` that essentially says: “A request to the `pharmacy-service` at path `/prescriptions/{id}` is only allowed if the incoming JWT claim `sub` (the user’s ID) matches the `{id}` in the path.” The application code itself never even sees a forbidden request. It only receives traffic that the mesh has already vetted.

This is the most complex and expensive option, but it’s also the most robust. It decouples security policy from application code, allowing your security team to manage rules without requiring developers to redeploy their services.

Comparing The Approaches

That Reddit thread is a stark reminder that the simplest attack vectors are often the most devastating. As engineers, our job isn’t just to make things work; it’s to imagine how they might fail. Don’t trust the client. Ever. Verify every request, build security into your patterns, and for goodness’ sake, don’t let a simple ID change be the key to your entire kingdom.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions