Cookies vs LocalStorage vs SessionStorage: Key Differences for Frontend Devs

💡 Understanding Browser Storage in JavaScript: localStorage vs sessionStorage vs Cookies If you're working in front-end development, managing data in the browser is something you do almost every day. But many developers still get confused between these three: 🔹 localStorage 🔹 sessionStorage 🔹 Cookies Let’s break it down with simple examples 👇 📌 1. localStorage (Persistent Storage) ✔ Data stays even after closing the browser ✔ No expiration time Example: #javascript // Store data localStorage.setItem("username", "Alex"); // Get data console.log(localStorage.getItem("username")); // Remove data localStorage.removeItem("username"); 👉 Use case: Save user preferences like theme (dark/light mode) 📌 2. sessionStorage (Temporary Storage) ✔ Data is cleared when the tab is closed ✔ Works per tab (not shared across tabs) Example: #javascript // Store data sessionStorage.setItem("sessionUser", "Alex"); // Get data console.log(sessionStorage.getItem("sessionUser")); 👉 Use case: Temporary form data or session-based info 📌 3. Cookies (Server Interaction + Expiry Control) ✔ Stored as small text data ✔ Can have expiration date ✔ Sent to server with every request Example: #javascript // Set cookie document.cookie = "user=Alex; expires=Fri, 31 Dec 2026 12:00:00 UTC; path=/"; // Read cookie console.log(document.cookie); 👉 Use case: Authentication, tracking, remembering login sessions ⚡ Quick Comparison: localStorage → Long-term storage sessionStorage → Temporary per tab Cookies → Server communication + expiry control 🚀 Pro Tip: Avoid storing sensitive data (like passwords/tokens) in localStorage or cookies without proper security measures. #javascript #frontenddevelopment #webdevelopment #coding #interviewprep #techlearning #immediatejoiner #hiring #requiter #jobseekers #ui #ux #react #javascript #frontend #growth

JWT(JSON web Token)--The Backbone of Modern Authentication. You log in to the app.... Then Magically stay logged in across the requests 👉no Session ,no repeated login comes into. How? And that magical concept is JSON Web Token(JWT). What Actually is It ? It's a compact,Secure way to transmit data between client and sever. Primarily used for stateless authentication and authorization. Structure of JWT (3 Parts) A JWT looks like this: header.payload.signature 1. Header: Contains Metadata { "alg": "HS256", "typ": "JWT" } ->Algorithm used for signing 2. Payload: Contains actual data (claims) { "user_id": 101, "role": "admin", "exp": 1712345678 } Types of claims: Registered (exp, iat, iss) Public Private ->Payload is NOT encrypted (only encoded) 3. Signature (Security Layer) Created using: HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), secret_key ) ->Ensures data is not tampered How JWT Works (Flow) 1-User logs in (username/password) 2-Server verifies credentials 3-Server generates JWT (signed with secret) 4-Client stores token (localStorage / cookies) 5-Client sends JWT in headers: Authorization: Bearer <token> 6-Server verifies signature 7-If valid → request allowed Why JWT is Powerful ✅ Stateless (no session storage) ✅ Scalable for microservices ✅ Fast authentication ✅ Works across domains (APIs, mobile apps) JWT in Django Used with: Django REST Framework (DRF) Libraries like SimpleJWT 👉 Helps build secure APIs & authentication systems Final Thought JWT is simple… but powerful 👉 It replaces traditional sessions with a stateless, scalable approach If you’re building: 📡 APIs 📱 Mobile apps 🌐 Microservices #JWT #Authentication #Django #Python #APIs #BackendDevelopment #WebSecurity #SoftwareDevelopment #webapplication

🔑 JavaScript Sets – Quick Revision Guide 1. What is a Set? A collection of unique values (no duplicates). Values can be any type: primitives or objects. 2. Creating Sets // From array const letters = new Set(["a", "b", "c"]); // Empty + add values const letters = new Set(); letters.add("a"); letters.add("b"); // Add variables const a = "a"; letters.add(a); 3. Adding Values Use .add(value) Duplicate values are ignored: letters.add("c"); letters.add("c"); // ignored 4. Iterating Sets for (const x of letters) { console.log(x); } 5. Type & Identity typeof letters; // "object" letters instanceof Set; // true 6. Browser Support Introduced in ES6 (2015). Supported in all modern browsers since 2017. 📝 Exercise Answer True or False: Each value can only occur once in a Set. 👉 Correct answer: True 🎯 Memory Hooks Set = Unique Collection Think of it as a mathematical set: no duplicates, only distinct members. ⚡ Quick Comparison: Set vs Array FeatureArraySet DuplicatesAllowed❌ Not allowed OrderIndexedInsertion order AccessBy indexBy value MethodsRich (map, filter, reduce)Focused (add, delete, has) This format makes it easy to scan, recall, and apply.

🚀 Learn in Public #5: What’s Really Running Under the Hood of My WebRTC Video Calling App? Hey everyone 👋 In my previous posts, I showed the UI improvements and a working demo of the video calling feature. This time, no fancy demo — let’s go behind the scenes and see exactly how the call actually works step by step. High-Level Overview Frontend: Vanilla HTML + CSS + JavaScript Backend: FastAPI acting purely as a signaling server (WebSocket) Authentication: JWT token + phone number as unique user ID Media: Direct peer-to-peer connection using WebRTC (FastAPI never sees the actual video or audio) The Call Flow – Under the Hood [Insert Mermaid Sequence Diagram Image Here] Step-by-step explanation: Both users log in using JWT and connect to the WebSocket endpoint: /ws/video-call/{phone_number} User 1 clicks the "Video Call" button on any online contact. User 1 creates RTCPeerConnection, gets camera + microphone access, creates an SDP Offer, and sends it to the signaling server. The FastAPI server forwards the incoming call notification to User 2 (popup appears). If User 2 accepts the call, User 2 creates an SDP Answer and sends it back through the signaling server. Both users set the received descriptions as remote descriptions. Both sides gather ICE candidates (using STUN and TURN servers) and exchange them via the signaling server. Once ICE negotiation completes successfully, a direct peer-to-peer connection is established between the two browsers. Audio and video streams now flow directly between User 1 and User 2 — completely bypassing the FastAPI server. Key Decisions I Made: Used a simple message structure with "type" field for easy maintenance Kept FastAPI only for signaling (not for media relay) to keep it lightweight Added multiple STUN + TURN servers for better NAT traversal and fallback (UDP preferred, then TCP when needed) Focused on understanding core WebRTC concepts before adding more features This is still early in the journey. The code is simple by design — easy to debug and improve. What’s Next? First, I plan to add screen sharing (which WebRTC supports natively). After that, I want to move from pure P2P to a server-side media path. This will allow better monitoring, tracking, security, and reliability — because in real-world applications, complete isolation isn’t always ideal. A more manageable and controllable system will be useful for many use cases. Would love to hear your thoughts! Have you worked with WebRTC? Any suggestions or questions? #LearnInPublic #WebRTC #FastAPI #WebDevelopment #JavaScript #RealTimeCommunication

Today I revised one of the most important topics in web development — HTTP Methods & Status Codes 🌐🔥 Every API call, website request, and frontend-backend communication depends on these fundamentals. 🔹 HTTP Methods = What action you want to perform 📥 GET Used to fetch data. Examples: get users, products, profile. 💡 Important: GET can send data using: ✔ Query params → /users?id=1 ✔ Headers ✔ Request body (possible in some clients, but browsers usually don’t support/rely on it) So in browsers, GET is mainly for reading data. 📤 POST Used to create new data. Example: register user, create order. ✏️ PUT Used to fully update data. 🩹 PATCH Used to partially update data. 🗑️ DELETE Used to remove data. 🔹 Why Methods Matter ✔ Clear API design ✔ Better communication ✔ Easy maintenance ✔ Security & caching benefits 🔹 Status Codes = What happened after request ✅ Success 200 OK → Success 201 Created → New resource created 204 No Content → Success, no response body ❌ Client Errors 400 Bad Request 401 Unauthorized 403 Forbidden 404 Not Found 💥 Server Errors 500 Internal Server Error 503 Service Unavailable 🧠 Big Realization HTTP Methods say: What you want to do Status Codes say: What happened #HTTP #APIs #WebDevelopment #BackendDevelopment #FrontendDevelopment #NodeJS #JavaScript #SoftwareEngineering #Programming #Developers #SystemDesign #Coding #TechExplained #DeveloperLife #LearnInPublic #BuildInPublic #Networking #TechCommunity #JavaScript #frontend #backend #fullstack #react #js #reactdeveloper #nodedeveloper #backendDeveloper #frontendDeveloper

There is a specific type of developer frustration that has nothing to do with your logic being wrong. Your code is correct. Your API is running. You have looked at everything and it looks fine. But the browser is still blocking you. It is silent and firm. It does not negotiate. That frustration has a name. And it is called CORS. What is CORS and why does it exist? CORS stands for Cross-Origin Resource Sharing. When your browser makes a request to a different domain than the one you're on - say your frontend at site-a.com trying to fetch data from api.site-b.com, the browser doesn't just allow it automatically. The browser asks some questions first. The browser sends a request with an Origin header. Sometimes it sends a preflight OPTIONS request before the actual one(asking for permission first). The preflight request is automatic. The server must respond with an Access-Control-Allow-Origin header giving explicit permission. If that header is missing or doesn't match? The browser blocks the request entirely. Not the server. The browser. That's why CORS errors feel invisible on the backend - because they're enforced on the frontend, protecting users from malicious sites silently reading their data across domains. Fixing CORS in Development. In development your frontend runs on one port - say localhost:3000, and your backend on another - localhost:5000. Different ports mean different origins. When the origins are different CORS will fire. Three ways to handle it locally: -> Use a proxy. Configure your frontend framework's dev server to forward requests to your backend. The browser sees a same-origin request. So CORS is never triggered. ->Temporarily allow all origins on your backend. Quick and effective for local development only. Browser extensions. A last resort. Extensions like "CORS Unblock" bypass the restriction quickly. But remember to disable them when done. They compromise your browser's security model entirely. So you have to be extremely careful with this one. Fixing CORS in Production. Development is about convenience. Production is about security. The rules change completely. One rule you should take note of - never use * in production. It is known as a wildcard and a wildcard means any website can access your API. That defeats everything CORS was built to protect. The correct approach is for you to specify your exact frontend domain in the backend. CORS errors feel like a wall. But they are actually a door - one that only opens when you configure it correctly on the server. Understand the mechanism once and you'll never be blindsided by that red console error again.

Today I explored something every developer uses daily — yet many don’t fully understand: HTTP Response Headers 🔥 And instead of just reading about them, I went hands-on. I built a raw TCP server and manually wrote the response headers myself. No frameworks. No shortcuts. Just fundamentals. 😎 🔹 What I actually did: ✔ Streamed a video file to the browser ✔ Controlled how the browser handled the response ✔ Sent headers manually over a TCP socket No Express. No HTTP libraries. Just raw TCP and full control. 🔹 Key headers I used (and why they matter): 🎬 Content-Type Tells the browser what type of data it’s receiving. Example: Content-Type: video/mp4 If this is wrong, the browser won’t know how to handle the file — play it, download it, or ignore it. 📏 Content-Length Specifies the exact size of the response. Why this matters: ✔ Enables download progress tracking ✔ Ensures complete file transfer ✔ Essential for streaming and large files ✔ Gives control over how much data is sent ⬇️ Content-Disposition Controls how the browser treats the file: ✔ inline → open or play inside the browser ✔ attachment → force a download Example: Content-Disposition: attachment; filename="video.mp4" This is how servers force downloads instead of in-browser playback. 🌍 CORS (Cross-Origin Resource Sharing) Example: Access-Control-Allow-Origin: * Determines whether a browser can accept this resource from another origin. Without it, the browser blocks the request ❌ I also tested exposing custom headers: Access-Control-Expose-Headers: hello This is crucial — without exposing it, JavaScript can’t read that custom header even if the server sends it. 🧠 Big takeaway: Servers don’t just send data. They instruct the browser on how to handle that data. With headers, you can: ✔ Control downloads ✔ Control streaming behavior ✔ Enable or restrict cross-origin access ✔ Improve performance ✔ Shape browser behavior 🔥 Why this matters: When I manually wrote headers over a TCP socket, I finally understood how browsers truly interpret server responses. This knowledge forms the foundation of: ✔ Web development ✔ APIs ✔ Streaming systems ✔ File handling ✔ System design If you want to level up as a backend engineer, don’t just rely on frameworks. Learn what’s happening underneath — it changes everything. #HTTP #Networking #BackendDevelopment #WebDevelopment #NodeJS #SystemDesign #SoftwareEngineering #Programming #Developers #TechExplained #APIs #Coding #DeveloperLife #LearnInPublic #BuildInPublic #TechCommunity #Engineering #WebPerformance #ViralPost #JavaScript #ReactJs #JS #NodeJS #Jobs #fullstack #frontend #backend #webdeveloper #RestfulApi #FullStackDeveloper #backendEngineer

🔍 How I Find DOM XSS in Real Applications (Not by luck. By methodology.) Most testers “try payloads.” Advanced testers trace execution. Here’s my step-by-step approach 👇 🧠 Step 1 — Identify SOURCES (Entry Points) I don’t start with payloads. I start with: 👉 Where can user input enter JavaScript? Common sources: location.href location.search location.hash document.cookie window.name 🎯 Goal: Find controllable input inside JS. 🔎 Step 2 — Track the FLOW Now I follow the data. Questions I ask: Is input being modified? Is it concatenated into strings? Is it passed into functions? Example: var q = location.search; var data = "Hello " + q; Looks harmless. Until it reaches a sink. 🔴 Step 3 — Find SINKS (Execution Points) This is where XSS happens. Dangerous sinks: innerHTML outerHTML document.write() eval() setTimeout() setInterval() Example: element.innerHTML = data; 💥 If you control data, you control execution. 🧪 Step 4 — Payload Crafting (Not Just ) Beginners use: <script>alert(1)</script> Real apps block this. So I test variations: ✔ Event-based: <img src=x onerror=alert(1)> ✔ SVG-based: <svg onload=alert(1)> ✔ Attribute injection: " onmouseover=alert(1) " ✔ JS context: ';alert(1);// 🧠 Mindset: “Where is my payload landing? HTML? Attribute? JS?” 🧩 Step 5 — Bypass Filters When blocked, I don’t stop. I adapt. Techniques: Encoding (URL / HTML) Case variation Breaking context Using different tags/events Chaining inputs Example: %3Csvg%20onload=alert(1)%3E ⚡ Step 6 — Validate Execution Not just alert. I check impact: Can I steal cookies? Can I access DOM data? Can I perform actions on behalf of user? 🎯 Interview-Ready Answers 👉 What is DOM XSS? Client-side vulnerability where user input is executed by JavaScript without server involvement. 👉 Why is it hard to detect? Because payload never reaches backend — it executes in browser runtime. 👉 How do you find it? By identifying sources, tracking data flow, and testing execution at sinks. 👉 Difference from reflected XSS? Reflected → server response DOM → client-side execution 👉 How to prevent? Avoid unsafe sinks (innerHTML) Use safe APIs (textContent) Proper input sanitization CSP (Content Security Policy) 🧠 Final Insight DOM XSS is not about payloads. It’s about data flow + execution context. If you understand the flow, you don’t need to guess the payload. 📌 Part of my journey: Networking → AppSec → Cloud Security Next: 🔥 Real-world DOM XSS case study #CyberSecurity #AppSec #DOMXSS #WebSecurity #BugBounty #VAPT #SecurityEngineering #JavaScriptSecurity #OWASP #LearningInPublic

𝗛𝗧𝗧𝗣 𝗦𝘁𝗮𝘁𝘂𝘀 𝗖𝗼𝗱𝗲𝘀 – 𝗦𝗺𝗮𝗹𝗹 𝗡𝘂𝗺𝗯𝗲𝗿𝘀, 𝗕𝗶𝗴 𝗠𝗲𝗮𝗻𝗶𝗻𝗴𝘀! As I continue my journey in web development, one thing I realized is… These small 𝙃𝙏𝙏𝙋 𝙨𝙩𝙖𝙩𝙪𝙨 𝙘𝙤𝙙𝙚𝙨 actually explain everything happening behind the scenes. From a successful API call to a server crash every response tells a story. And once you start understanding them, debugging becomes much easier and faster.. 𝙇𝙚𝙩’𝙨 𝙨𝙞𝙢𝙥𝙡𝙞𝙛𝙮 𝙩𝙝𝙚𝙢 𝙩𝙤𝙜𝙚𝙩𝙝𝙚𝙧 👇: ━━━━━━━━━━━━━━━━━━━━━━━ 🟢 𝗦𝘂𝗰𝗰𝗲𝘀 (2xx) ✔ 200 OK → Everything worked perfectly ✔ 201 Created → New resource created ✔ 202 Accepted → Request received, processing ✔ 204 No Content → Success, but no response body 👉 𝙏𝙝𝙞𝙨 𝙞𝙨 𝙬𝙝𝙖𝙩 𝙬𝙚 𝙡𝙤𝙫𝙚 𝙩𝙤 𝙨𝙚𝙚 𝙖𝙨 𝙙𝙚𝙫𝙚𝙡𝙤𝙥𝙚𝙧𝙨 ━━━━━━━━━━━━━━━━━━━━━━━ 🔁 𝗥𝗲𝗱𝗶𝗿𝗲𝗰𝘁𝗶𝗼𝗻 (3xx) ✔ 301 Moved Permanently → URL changed forever ✔ 302 Found → Temporary redirect ✔ 304 Not Modified → Use cached version 👉 𝙄𝙢𝙥𝙧𝙤𝙫𝙚𝙨 𝙥𝙚𝙧𝙛𝙤𝙧𝙢𝙖𝙣𝙘𝙚 & 𝙎𝙀𝙊 𝙬𝙝𝙚𝙣 𝙪𝙨𝙚𝙙 𝙘𝙤𝙧𝙧𝙚𝙘𝙩𝙡𝙮 ━━━━━━━━━━━━━━━━━━━━━━━ ⚠️ 𝗖𝗹𝗶𝗲𝗻𝘁 𝗘𝗿𝗿𝗼𝗿𝘀 (4xx) ✔ 400 Bad Request → Invalid data ✔ 401 Unauthorized → Login required ✔ 403 Forbidden → No permission ✔ 404 Not Found → Page/resource missing ✔ 405 Method Not Allowed → Wrong HTTP method ✔ 408 Request Timeout → Took too long 👉 𝙈𝙤𝙨𝙩 𝙘𝙤𝙢𝙢𝙤𝙣 𝙚𝙧𝙧𝙤𝙧𝙨 𝙬𝙚 𝙙𝙚𝙗𝙪𝙜 𝙙𝙖𝙞𝙡𝙮! ━━━━━━━━━━━━━━━━━━━━━━━ 🔥 𝗦𝗲𝗿𝘃𝗲𝗿 𝗘𝗿𝗿𝗼𝗿𝘀 (5xx) ✔ 500 Internal Server Error → Something broke ✔ 501 Not Implemented → Not supported ✔ 502 Bad Gateway → Invalid response ✔ 503 Service Unavailable → Server overloaded ✔ 504 Gateway Timeout → Server too slow 👉 𝙏𝙝𝙚𝙨𝙚 𝙣𝙚𝙚𝙙 𝙞𝙢𝙢𝙚𝙙𝙞𝙖𝙩𝙚 𝙖𝙩𝙩𝙚𝙣𝙩𝙞𝙤𝙣 𝙞𝙣 𝙥𝙧𝙤𝙙𝙪𝙘𝙩𝙞𝙤𝙣 ━━━━━━━━━━━━━━━━━━━━━━━ 𝗪𝗵𝗮𝘁 𝗜 𝗟𝗲𝗮𝗿𝗻𝗲𝗱: Instead of just seeing errors, I started understanding them. And that changed how I debug, build APIs, and handle real-world applications. 𝘾𝙤𝙣𝙨𝙞𝙨𝙩𝙚𝙣𝙘𝙮 𝙞𝙣 𝙡𝙚𝙖𝙧𝙣𝙞𝙣𝙜 𝙨𝙢𝙖𝙡𝙡 𝙘𝙤𝙣𝙘𝙚𝙥𝙩𝙨 𝙡𝙞𝙠𝙚 𝙩𝙝𝙞𝙨 𝙗𝙪𝙞𝙡𝙙𝙨 𝙨𝙩𝙧𝙤𝙣𝙜 𝙛𝙤𝙪𝙣𝙙𝙖𝙩𝙞𝙤𝙣𝙨.. ━━━━━━━━━━━━━━━━━━━━━━━ 𝗙𝗶𝗻𝗮𝗹 𝗧𝗵𝗼𝘂𝗴𝗵𝘁: Every status code is a message. If you understand it, you’re already one step ahead as a developer. #WebDevelopment #FullStackDeveloper #HTTP #APIs #Coding #DeveloperLife #Programming #SoftwareDevelopment #DevCommunity #Debugging #RESTAPI #BackendDevelopment #SystemDesign #CodeNewbie #100DaysOfCode #JavaScript #ReactJS #Consistency #TechJourney #WomenInTech #DevakiCodes #CodeEveryday #pvndevakiJobFindingBegins