Dhivya P’s Post

Most developers treat auth as solved. It isn't. The mechanism you choose has deep consequences for security, scale, and architecture. Here's the real breakdown no one explains properly: Cookies are exceptional — for browsers. When a user logs in, the server sets a cookie. From that point, the browser handles everything: storage, transport, expiry. No client-side code needed. Three flags make this genuinely secure: → HttpOnly — JS can't read the token. XSS can't steal it. → Secure — HTTPS only. → SameSite — neutralizes CSRF in modern browsers. For a classic web app, cookies are still the cleanest auth solution that exists. But browsers aren't the whole world. Cookies are browser-native. That's the ceiling. Mobile apps, CLI tools, microservices — none of them benefit from automatic cookie handling. You're fighting CORS when your frontend, API, and auth service live on different domains. And third-party cookies are actively dying — ITP and browser privacy features are accelerating that fast. So what do you actually use? It depends entirely on what you're building: → Bearer tokens (JWT) — stateless, works across domains, ideal for APIs and SPAs. Tradeoff: storage is your problem. localStorage is an XSS risk. Memory is safer. → API keys — dead simple for server-to-server. No user identity, no session overhead. Don't use them where user-level auth matters. → OAuth / OIDC — "Login with Google" territory. Standardized, scoped, federated. Complex for a reason — don't add this complexity if you don't need it. → Hybrid (cookies + headers) — the right call when you're serving both browsers and external clients simultaneously. The mistake most engineers make: Picking one auth model and forcing it everywhere. Cookies in a distributed system = pain. JWTs in a simple session-based web app = unnecessary complexity. Good auth design isn't about finding the "best" mechanism. It's about matching the mechanism to the client model. Know your clients. Then choose. #BackendDevelopment #SystemDesign #Authentication #SoftwareArchitecture #CyberSecurity #WebSecurity

🔐 Why Content Security Policy (CSP) is a Must for Modern Web Apps Most developers focus on features. But real-world apps fail because of security gaps 👀 One of the most underrated protections? 👉 CSP (Content Security Policy) 💡 Why CSP? CSP helps prevent XSS (Cross-Site Scripting) attacks, where attackers inject malicious scripts into your website. Without CSP: ❌ Attackers can run scripts in your users' browsers ❌ Steal session cookies / tokens ❌ Redirect users to malicious sites With CSP: ✅ Only trusted sources can run scripts ✅ Browser blocks injected code automatically ✅ Your app becomes much harder to exploit 🧠 When should you use CSP? 👉 Always — especially if your app has: User input (forms, comments, search) Dynamic content rendering Authentication (login systems) Admin dashboards ⚙️ Real-world usage In Laravel (or any backend), CSP is applied using headers: Define what sources are allowed (script-src, style-src, etc.) Block inline scripts by default Allow only trusted CDNs or your own domain ⚠️ Important reality When you enable CSP: ❌ Inline JS breaks ❌ Inline CSS breaks ❌ onclick and inline handlers stop working 👉 And that’s GOOD. Because CSP forces you to write clean, secure code 🚀 Final Thought CSP doesn’t just protect your app — It trains you to build like a security-first developer Link: https://lnkd.in/gchdNTt7 💬 Are you using CSP in your projects yet? #WebSecurity #Laravel #CSP #XSS #Developers #Backend #Frontend

Day 14 of 365: Web Developer → AppSec This week changed how I see every web app I have ever built. HTTP requests are just text. That’s it. When your browser loads a website, it sends a plain text message like: GET /login HTTP/1.1 Host: example.com Cookie: session=abc123 I ran a single command: curl -v http://example.com And watched the entire conversation happen in real time. No browser. No UI. Just raw text moving across the internet. Here’s the shift: As developers, we think in buttons, forms, APIs. Attackers think in requests. Every web attack is just a manipulated version of that same text. SQL Injection? A modified request. XSS? A modified request. Session hijacking? A stolen cookie from that request. What this really means is: If you don’t understand the request, you don’t understand the attack. Week 2 done. Still going. #AppSec #WebSecurity #HTTP #LearningInPublic #365DaysOfHacking #PenetrationTesting

The hidden cost: That small oversight in your API key management could expose your app. If your Anthropic Claude API practices aren't airtight, you might be one misstep away from serious security issues. What's inside: → Proper configuration of your API key environment → Streamlining API calls with Node.js → Detecting and fixing common security leaks Discover the details: https://lnkd.in/dqh9qMhm #AIIntegration #NodeSecurity #ClaudeAPI

Your API has no rate limiter. That means anyone can do this: for (let i = 0; i < 100000; i++) {  fetch('/api/login', { method: 'POST', body: credentials }); } Brute-force your login endpoint. Scrape all your data. Crash your server with a burst. Rate limiting is not optional. Here's how I implement it in Express/Node.js: import rateLimit from 'express-rate-limit'; const loginLimiter = rateLimit({  windowMs: 15 * 60 * 1000, // 15 minutes  max: 10, // max 10 login attempts per window  message: { error: 'Too many attempts. Try again in 15 minutes.' },  standardHeaders: true,  legacyHeaders: false, }); app.post('/api/auth/login', loginLimiter, authController.login); Different endpoints need different limits: → Login: strict (10/15min) — brute force target → Public search: relaxed (100/min) — UX matters → File upload: very strict (5/hour) — resource cost I added this to every project after forgetting it in my first one. Security is not a feature you add at the end. It's a constraint you build around from day 1. #Backend #Security #NodeJS #APIDesign #WebSecurity

🚀 Introducing the HackTools Web App — Now Live Excited to share that we’ve launched the HackTools web application to make it easier to explore and access the platform outside the extension. 🌐 https://lnkd.in/gJM69r66 HackTools is a browser-native security testing platform designed to bring BurpSuite-like capabilities directly into developer workflows. The new web app provides a centralized place to understand features, workflows, and upcoming updates. With HackTools, you can: • Capture and replay HTTP requests • Perform smart fuzzing using Intruder • Run passive security scans • Detect technologies with CVE intelligence • Identify exposed secrets and tokens • Perform WordPress security audits The goal is to make security testing lightweight, fast, and developer-friendly — directly inside the browser. The web app is just the beginning. We’re planning: • Feature documentation • Interactive demos • AI-powered testing workflows • Community-driven feedback Would love feedback from AppSec engineers, bug bounty hunters, and developers. #HackTools #CyberSecurity #AppSec #BugBounty #SecurityTools #BuildInPublic #DevTools #Startup HackerOne Bugcrowd Facebook

Introducing the HackTools Web App — Now Live Excited to share that we’ve launched the HackTools web application to make it easier to explore and access the platform outside the extension. 🌐 https://lnkd.in/gJM69r66 HackTools is a browser-native security testing platform designed to bring BurpSuite-like capabilities directly into developer workflows. The new web app provides a centralized place to understand features, workflows, and upcoming updates. With HackTools, you can: • Capture and replay HTTP requests • Perform smart fuzzing using Intruder • Run passive security scans • Detect technologies with CVE intelligence • Identify exposed secrets and tokens • Perform WordPress security audits The goal is to make security testing lightweight, fast, and developer-friendly — directly inside the browser. The web app is just the beginning. We’re planning: • Feature documentation • Interactive demos • AI-powered testing workflows • Community-driven feedback Would love feedback from AppSec engineers, bug bounty hunters, and developers. #HackTools #CyberSecurity #AppSec #BugBounty #SecurityTools #BuildInPublic #DevTools #Startup HackerOne Bugcrowd Facebook

I've seen production apps go down because of bad auth choices. Not from bad code but from Bad decisions. Here's the auth cheat sheet nobody gives you early enough: Basic Auth — username + password in every request header. Works in 5 minutes but Breaks trust in 5 seconds if you're not on HTTPS. Never use it alone in production. Session Auth — server remembers you. Great for web apps, terrible when you're scaling horizontally across 10 servers. Sticky sessions become your nightmare. Token Auth — server forgets you the moment you leave. You carry proof of identity in every request. It is Stateless, clean, scalable. JWT — token auth with a twist. The token is the user data, cryptographically signed. No database lookup needed for this, Just don't store sensitive info in the payload because it's encoded, not encrypted. OAuth2 — "Login with Google" is OAuth2. You're not handling passwords but You're delegating trust to someone who does it better and Smart. API Keys — simple, effective, easy to rotate. The go-to for service-to-service communication. Treat them like passwords. MFA — password alone is a single point of failure. MFA means a breach of one factor isn't a breach of your system. My Personal Recommendation: → Building something quick? Session auth. → Building an API? JWT or OAuth2. → Handling real users in production? MFA + OAuth2. #Programming #SoftwareEngineering #Development

Session-Based vs JWT-Based Authentication Every web app needs authentication. But how you manage it after login matters more than most developers realize. There are two dominant approaches: session-based and JWT-based. They solve the same problem differently. Session-Based Authentication: The user logs in, and the server creates a session and stores it in a session store. The client gets a session_id cookie. On every subsequent request, the browser sends that cookie, and the server looks up the session to validate it. The state lives on the server. That's the key tradeoff. It's simple and easy to revoke, but now your backend has to manage that session store. JWT-Based Authentication: The user logs in, and the server validates credentials, then creates and signs a token using a secret or private key. That token is sent back to the client. On every subsequent request, the client sends it as a Bearer token in the Authorization header. The server verifies the signature and reads the claims. No session store needed. The state lives in the token itself. The server stays stateless, which makes horizontal scaling straightforward. Over to you: what’s your go-to approach for auth in microservices? -- Subscribe to our weekly newsletter to get a Free System Design PDF (368 pages): https://lnkd.in/gauQcE45 #systemdesign #coding #interviewtips  .

I used to think JWT was always the “better” option — until I actually had to deal with token expiry and revocation. - Sessions feel more controlled and predictable, especially for smaller systems. - JWT definitely shines when you need scalability, but it comes with its own set of headaches. Interesting how the “right choice” really depends on the system design rather than just the trend.