Request Shield — a security checkpoint for outbound API requests

Huzaifa Awan — Fri, 23 Oct 2026 10:24:16 +0000

I built Request Shield — a security checkpoint for outbound API requests.

Before your application sends a request to another server, Request Shield inspects its metadata and returns one of three verdicts:
✅ Allow
⚠️ Review
🛑 Block

It currently checks for:
• SQL and command injection patterns
• SSRF and private-network destinations
• Exposed API keys and credentials
• Dangerous routing headers
• XSS and path traversal patterns
• Unsafe methods, URLs, content types, and payload sizes

Developers can integrate it through a REST endpoint, Node/TypeScript wrapper, AI installation prompt, or MCP configuration.

I’ve launched it as a free public beta with 100 checks per day. Every security check is included—there’s no feature paywall.

There’s also an interactive playground with safe and malicious sample requests, plus copy-and-paste Postman tests.

Try it here: https://request-shield-web.vercel.app/

I’d especially appreciate feedback on:

Installation clarity
False positives or missed threats
Features needed before using it in production

Request Shield is an additional security layer, not a replacement for validation, authorization, rate limiting, or a WAF.

How I Hit a 95% Redis Cache Hit Rate Under Real Load

Huzaifa Awan — Sun, 19 Jul 2026 07:56:57 +0000

On a multi-tenant SaaS dashboard I work on, response times climbed as concurrency grew. The fix was not a bigger server. It was a Redis caching strategy layered onto a .NET Core API. The result: a 95% cache hit rate and sub-50ms responses under 100+ concurrent users. Here is the actual process, not the highlight reel.

Measure before you cache

Caching the wrong thing hides problems and creates new ones. I started by profiling the API under realistic load to find the true hotspots: the endpoints that were both frequently hit and expensive to compute. Almost all the pain came from a handful of dashboard reads that ran heavy SQL Server aggregations on every request.

Frequent + expensive = cache it.
Frequent + cheap = probably leave it.
Rare + expensive = optimize the query, do not cache.

Cache-key design is the whole game

A cache is only as good as its keys. For a multi-tenant app, every key has to be scoped to the tenant and to the exact parameters that change the result: date range, filters, locale. Get this wrong and you either leak data across tenants or get a hit rate near zero because no two keys ever match.

dashboard:{tenantId}:kpis:{from}:{to}:{locale}
dashboard:{tenantId}:queue:live
catalog:{tenantId}:lowstock

Flat, predictable, and self-documenting. When a key names exactly what it holds, invalidation becomes obvious instead of guesswork.

Invalidation without the footguns

The famous hard problem. I leaned on two techniques: short, tuned TTLs for data that is allowed to be a few seconds stale (KPI roll-ups), and event-driven invalidation for data that must be fresh: when a write happens, the specific keys it affects are evicted immediately. Mixing the two keeps the hit rate high without ever showing a user stale-but-important data.

Verify the hit rate is real

A 95% hit rate only means something if you measure it under production-like concurrency, not a single-user test. I tracked hits, misses, and p95 latency while ramping concurrent users, and watched the cache warm and hold. That is also how you catch a key that looks cached but never actually matches.

The takeaways

Profile first. Cache the endpoints that are frequent and expensive, nothing else.
Scope keys to the tenant and every parameter that changes the result.
Combine tuned TTLs with event-driven eviction so fresh data stays fresh.
Prove the hit rate under real concurrency, not on your laptop.

Performance work like this, turning a slow app that scales poorly into a fast one, is a big part of what I do. See more of my work or reach out if your app is starting to feel the load.

Originally published at huzaifaawan.com. I am Muhammad Huzaifa Awan, a Senior Full Stack Developer building SaaS, AI products, and MCP servers. More writing and my portfolio live at huzaifaawan.com.