The network for creativity
Join 1.25M professional creatives like you
Connect with clients, get discovered, and run your business 100% commission-free
Creatives on Contra have earned over $150M and we are just getting started
Back to feedPost
A honeybee hive doesn't defend itself the same way everywhere.
Researchers sampling 24 colonies in Australia found the hive splits its chemistry by job: honey leans on hydrogen peroxide, propolis uses flavonoids, the fermented pollen stores run on short-chain acids. The strongest layer always sits right around the brood, the part that can't defend itself. The exposed edges get a different, broader mix.
Here's the part that got me: the best predictor of how potent any of it was wasn't the colony's disease history. It was which apiary the hive sat in, what was actually blooming nearby right now.
Most security and validation passes I see on a site get built the same way: harden whatever broke last time, leave everything else at the default. The one form that already survived an attack ends up bulletproof. The brand-new upload field nobody's attacked yet gets nothing.
Current exposure, not last year's incident report, is what should decide where the extra layer goes.
Where in your current build is the strongest safeguard sitting on the thing that already proved it was fine, instead of the thing that's actually exposed right now?
The network for creativity
Join 1.25M professional creatives like you
Connect with clients, get discovered, and run your business 100% commission-free
Creatives on Contra have earned over $150M and we are just getting started
Related posts
Casemate: making malware analysis feel calm instead of scary
Cybersecurity websites usually look the same: black background, green code, a hooded guy. I wanted to try the opposite for Casemate, a concept for a malware analysis tool.
The idea is simple: the product keeps a suspicious file in a sealed chamber and watches what it does. So I put a bug frozen in amber in the middle of a canyon. It’s dangerous and under control at the same time, and you get it without reading a word.
Then I made sure the page still works for a security lead who wants facts. The stats sit right next to the headline: threats isolated, latency, endpoints covered.
The hardest part was keeping it warm without losing trust. I stayed with one terracotta colour, wide capitals and mono labels, so it reads like a serious tool and not a poster.
I’m taking on new projects for SaaS and tech teams. If you have a product that’s hard to explain in one glance, send me a message.
What do you think, would you trust a security product with a canyon on the homepage?
I love it! It feels so calm, and I would definitely try it! This is amazing, Kris. I never thought cybersecurity could be this cool ❤️🔥
Is AI finally good enough to shoot a product demo on its own, or human touch is still needed?
I generated a 20s product demo with Seedance 2.5 in a single take providing it with one product image reference and an example video transcript (posted in the comments). Do you disclose to a client how much AI is involved, or just let the result speak for itself?
Is AI finally good enough to shoot a product demo on its own, or human touch is still needed?
I generated a 20s product demo with Seedance 2.5 in a single take providing it with one product image reference and an example video transcript (posted in the comments).
Do you disclose...
Rate limiting isn’t “npm install + two lines in nginx.”
Most tutorials make it look trivial: add a throttler package to NestJS, add limit_req to nginx, done.
Problem 1: your server sees the proxy, not the user.
Behind nginx, every request arrives from the proxy’s IP. So the whole site shared ONE rate limit. Ten login attempts per minute for everyone. Anyone could lock all users out.
The fix is one line in main.ts (app.set('trust proxy', 1)) plus forwarding X-Forwarded-For in nginx. The number matters: true trusts any client-supplied header and lets attackers spoof their IP. 1 trusts exactly one hop.
Problem 2: CSR and SSR see different IPs.
Client-side calls (login, refresh) go browser --> nginx --> API, so the API sees the real user IP.
But with Next.js SSR on a serverless platform like Vercel, the page is rendered on Vercel’s servers. The API sees a pool of cloud IPs, not your visitors. Every SSR visitor shares the same few IPs, and therefore the same quota.
The fix: the SSR layer forwards the visitor’s IP in a custom header, signed with a shared secret. The API only trusts that header when the secret matches. Without the secret check, anyone could forge the header and bypass your limits.
Lesson: rate limiting is an architecture problem, not a package. Know where your IP is lost, and who you trust.
