In every software project, there are moments where technical expertise is tested not by code complexity, but by human behaviour. On one of my projects, I faced such a moment when a mobile developer on the team went rogue.
He became unprofessional, violated trust, and refused to respect NDA terms or return the mobile app code that consumed our APIs. The bigger risk was not the code itself, but the fact that he still had an active client wired directly to our backend APIs. If left unchecked, he could continue consuming and potentially misusing our services indefinitely.
The team needed a solution, and I was asked to take control of the situation.
My Approach
I decided the best way to handle this was professionally and technically, without confrontation. Instead of chasing the developer, I focused on what I could control: the APIs.
The answer lay in implementing API Access Control, combining two mechanisms:
- A kill switch to disable APIs entirely when needed.
- Key-based restrictions to ensure only authorized clients could access endpoints.
This gave us immediate leverage and allowed us to continue operating without disruption.
The Middleware I Wrote
I created a custom Laravel middleware called DisableApiAccess that enforced these controls.
1. API Kill Switch
$apiAccess = filter_var(env('API_ACCESS', true), FILTER_VALIDATE_BOOLEAN);
if ($apiAccess === false) {
if ($request->expectsJson() || $request->is('api/*')) {
return apiresponser(503, 'API access is temporarily disabled.', null);
}
abort(503, 'Service unavailable.');
}
By flipping a single environment variable (API_ACCESS=false), I could immediately shut down all API endpoints with an HTTP 503 response. This was my emergency brake, no redeployments, no code edits, just an instant cut-off.
2. API Key Enforcement
$expectedKey = env('API_ACCESS_KEY');
if (!empty($expectedKey) && ($request->expectsJson() || $request->is('api/*'))) {
$provided = $request->header('X-API-ACCESS-KEY') ?? $request->header('Api-Access-Key');
if (empty($provided)) {
return apiresponser(401, 'API access key missing.', null);
}
if (!hash_equals((string) $expectedKey, (string) $provided)) {
return apiresponser(401, 'Invalid API access key.', null);
}
}
With an API_ACCESS_KEY configured, every request now required the correct header (X-API-ACCESS-KEY or Api-Access-Key).
- Missing header → 401 Unauthorized.
- Wrong key → 401 Unauthorized.
- Correct key → proceed as normal.
I also used hash_equals() for constant-time comparison to prevent timing attacks.
3. Normal Flow
return $next($request);
If the request passed both checks, it continued safely to the controller. If not, it was blocked at the middleware layer, long before touching business logic or the database.
The Flow Diagram
Here is how the request flow looked after I put the middleware in place:
┌─────────────────────────┐
│ Incoming API Request │
└─────────────┬───────────┘
│
▼
┌──────────────────┐
│ Middleware: │
│ DisableApiAccess │
└─────────┬────────┘
│
Is API_ACCESS=false?
│ │
YES NO
│ │
▼ ▼
┌────────────┐ Check if API_ACCESS_KEY is set
│ Return 503 │ │
│ Service │ │
│ Unavailable │ ▼
└────────────┘ Key Required?
│
┌─────┴─────┐
│ │
NO │ │ YES
│ ▼
▼ Validate Header
Allow Request │
▼
┌─────────────────────┐
│ Valid Key? │
└─────┬───────────────┘
│
┌──────┴───────┐
│ │
YES NO
│ │
▼ ▼
┌────────────────┐ ┌──────────────┐
│ Proceed to │ │ Return 401 │
│ Controller │ │ Unauthorized │
└────────────────┘ └──────────────┘
The Result
By putting this in place, I was able to:
- Revoke access immediately for the rogue developer, without touching his app or escalating the conflict.
- Secure the backend APIs so that only trusted clients with the right key could access them.
- Give the team confidence that we were still in control of the system, regardless of what happened with the mobile code.
The developer still had his app, but without valid API access, it was useless.
Why This Was Important
What I implemented aligned with industry best practices:
- 🔒 Zero Trust Principles – Never assume a client is trustworthy just because it was once authorized.
- ⚡ Operational Control – The kill switch provided instant response capability in case of emergencies.
- 🛡️ Defense in Depth – Unauthorized requests were stopped at the middleware layer, before causing harm.
- 📈 Professional Conflict Resolution – I avoided unnecessary escalation, kept the team’s integrity intact, and let the system enforce the rules.
Lessons Learned
- APIs must be treated as critical assets. Anyone with client access can become a risk.
- Revocation paths are non-negotiable. It is not enough to grant access; you must always have a way to revoke it.
- Leadership often means quiet technical decisions. Instead of drama, I solved the issue with clean code and precise safeguards.
Final Thoughts
In the end, I did not just block a rogue developer, I safeguarded the project and gave my team a way forward.
This experience reinforced something I now apply in every system I design: control must be baked into the architecture, not assumed through trust.
When asked to protect the team and the project, I did it not with confrontation, but with a simple, robust solution: API Access Control.
But this is just one approach. If you were in my shoes, what other strategies would you have considered to keep the APIs safe without escalating the conflict? I would love to hear your thoughts. Please share them in the comments so we can learn from each other’s perspectives.
Top comments (0)