Mike Schwartz’s Post

Understanding API Permissions in Search Engines:: General API Permission Requirements: Search engines typically require permissions to access various APIs. This is essential for ensuring user privacy and security. Permissions are often granted on a case-by-case basis, depending on the specific API being accessed. Types of Permissions:: User Consent: Users must explicitly grant permission for an application to access their data or devices. Scope of Access: Permissions can be limited to specific functionalities, such as reading data or controlling devices. How Permissions Are Managed:: Permissions API: This API allows developers to check and request permissions programmatically. It provides a consistent way to manage permissions across different APIs. Requesting Permissions: If an application does not have the necessary permissions, it can prompt the user to grant access. This is done through a user interface that explains what access is needed. Example of Permission Flow:: Check Permissions: The application checks if it has the required permissions. Request Permissions: If not granted, the application requests permissions from the user. Access API: Once permissions are granted, the application can access the API. In summary, search engines do require permissions for each API they connect to, ensuring that user data is handled securely and with consent. xgdcv

𝐉𝐖𝐓 (JSON Web Tokens) ◾ JSON Web Token (JWT) => open standard (RFC 7519) for securely transmitting information between parties as a JSON object. ◾ a compact and self-contained way to represent a set of claims securely between two parties. 📌 𝐒𝐭𝐫𝐮𝐜𝐭𝐮𝐫𝐞 𝐨𝐟 𝐚 𝐉𝐖𝐓 A JWT consists of three parts => separated by dots (.) [1.] 𝐇𝐞𝐚𝐝𝐞𝐫 ◾ Specifies the algorithm used to sign the token (e.g., HS256, RS256) and the type of the token, which is always JWT. [2.] 𝐏𝐚𝐲𝐥𝐨𝐚𝐝 (Claims) ◾ Contains the claims (statements) about an entity (typically, the user) and additional data. There are three types of claims - ◾ Registered claims (standardized): iss (issuer), exp (expiration time), sub (subject), aud (audience) etc. ◾ Public claims (customizable by your application). ◾ Private claims (application-specific agreements). [3.] 𝐒𝐢𝐠𝐧𝐚𝐭𝐮𝐫𝐞 ◾ Created by taking - a. the encoded header b. the encoded payload c. a secret d. signing it with the algorithm specified in the header ◾ Used to verify the token's authenticity and integrity. 📌 𝐁𝐞𝐧𝐞𝐟𝐢𝐭𝐬 𝐨𝐟 𝐔𝐬𝐢𝐧𝐠 𝐉𝐖𝐓𝐬 ◾ Auth ◾ Statelessness => server doesn't need to store session information. ◾ Security =>can be signed using various algorithms ◾ Decentralization => ideal for single sign-on (SSO). 📌 𝐉𝐖𝐓 𝐁𝐞𝐬𝐭 𝐏𝐫𝐚𝐜𝐭𝐢𝐜𝐞𝐬 JWTs are a tool, not a complete security solution. Their security hinges on proper implementation and usage. 👍 [1.] Algorithm Selection ◾ Prioritize Asymmetry - Use RS256 (RSA) or ES256 (Elliptic Curve) for stronger security. ◾ Avoid HS256 - HMAC-based signing (HS256) requires careful key management. ◾ Never Use 'none' - This disables signing, rendering JWTs completely insecure. [2.] Key Management ◾ Generate robust, cryptographically secure keys (256-bit or higher). ◾ Regularly rotate keys. [3.] Secure Storage ◾ Store keys securely, never in source code or version control. [4.] Claim Usage ◾ Avoid storing sensitive or personally identifiable information (PII) directly in JWT claims. ◾ Utilize standard claims (iss, exp, aud, sub) consistently. ◾ For sensitive data, encrypt the JWT payload. [5.] Token Handling ◾ Transmit JWTs exclusively over HTTPS to prevent interception. ◾ Store JWTs in HttpOnly cookies to protect against cross-site scripting (XSS) attacks. ◾ Set short expiration times and consider refresh tokens for longer sessions. ◾ Implement mechanisms for revoking compromised tokens =>blacklists, short-lived tokens. [6.] Validation and Verification ◾ ALWAYS verify the JWT signature using the appropriate algorithm and key before processing the claims. ◾ Check all relevant claims (exp, iss, aud) for validity and relevance to your application. => Implement rate limiting to protect against brute-force attacks. =>Use security-focused HTTP headers to enhance protection. -------------- 👍 Follow - Mayank 🗒️ Free Newsletter - https://lnkd.in/dJByxEYY #softwaredevelopment

𝗔𝘂𝘁𝗵𝗲𝗻𝘁𝗶𝗰𝗮𝘁𝗶𝗼𝗻 & 𝗔𝘂𝘁𝗵𝗼𝗿𝗶𝘇𝗮𝘁𝗶𝗼𝗻 𝗶𝗻 𝗔𝗦𝗣.𝗡𝗘𝗧 𝗖𝗼𝗿𝗲 Imagine a 𝗺𝗼𝘃𝗶𝗲 𝘁𝗵𝗲𝗮𝘁𝗿𝗲: • The 𝘁𝗶𝗰𝗸𝗲𝘁 𝗰𝗵𝗲𝗰𝗸𝗲𝗿 verifies 𝘸𝘩𝘰 𝘺𝘰𝘶 𝘢𝘳𝘦 → That’s 𝗔𝘂𝘁𝗵𝗲𝗻𝘁𝗶𝗰𝗮𝘁𝗶𝗼𝗻. • The 𝘂𝘀𝗵𝗲𝗿 checks 𝘸𝘩𝘪𝘤𝘩 𝘴𝘤𝘳𝘦𝘦𝘯 𝘺𝘰𝘶 𝘤𝘢𝘯 𝘦𝘯𝘵𝘦𝘳 → That’s 𝗔𝘂𝘁𝗵𝗼𝗿𝗶𝘇𝗮𝘁𝗶𝗼𝗻. 𝗪𝗵𝗮𝘁 𝗶𝘀 𝗔𝘂𝘁𝗵𝗲𝗻𝘁𝗶𝗰𝗮𝘁𝗶𝗼𝗻? Verifies 𝘄𝗵𝗼 𝘁𝗵𝗲 𝘂𝘀𝗲𝗿 𝗶𝘀 (Identity). For example: • Login using username/password. • Login via Google, Facebook, or Microsoft.  𝗪𝗵𝗮𝘁 𝗶𝘀 𝗔𝘂𝘁𝗵𝗼𝗿𝗶𝘇𝗮𝘁𝗶𝗼𝗻? Determines 𝘄𝗵𝗮𝘁 𝘁𝗵𝗲 𝘂𝘀𝗲𝗿 𝗰𝗮𝗻 𝗱𝗼 (Permissions). For example: • Admin can manage users. • Normal user can only view data. 𝗔𝘂𝘁𝗵𝗲𝗻𝘁𝗶𝗰𝗮𝘁𝗶𝗼𝗻 𝗙𝗹𝗼𝘄 𝗶𝗻 𝗔𝗦𝗣.𝗡𝗘𝗧 𝗖𝗼𝗿𝗲 1. User sends credentials (username/password). 2. Server validates and creates a 𝘁𝗼𝗸𝗲𝗻 (𝗝𝗪𝗧) or session. 3. Token is attached to future requests. 4. Middleware checks token → grants access if valid.  𝗘𝘅𝗮𝗺𝗽𝗹𝗲: 𝗨𝘀𝗶𝗻𝗴 𝗝𝗪𝗧 𝗔𝘂𝘁𝗵𝗲𝗻𝘁𝗶𝗰𝗮𝘁𝗶𝗼𝗻 𝗦𝘁𝗲𝗽 𝟭: 𝗖𝗼𝗻𝗳𝗶𝗴𝘂𝗿𝗲 𝗦𝗲𝗿𝘃𝗶𝗰𝗲𝘀 (𝗣𝗿𝗼𝗴𝗿𝗮𝗺.𝗰𝘀) builder.Services.AddAuthentication("Bearer")   .AddJwtBearer(options =>   {     options.Authority = "https://your-auth-server";     options.Audience = "your-api";   }); builder.Services.AddAuthorization(); 𝗦𝘁𝗲𝗽 𝟮: 𝗨𝘀𝗲 𝗠𝗶𝗱𝗱𝗹𝗲𝘄𝗮𝗿𝗲 app.UseAuthentication(); app.UseAuthorization(); 𝗦𝘁𝗲𝗽 𝟯: 𝗣𝗿𝗼𝘁𝗲𝗰𝘁 𝗖𝗼𝗻𝘁𝗿𝗼𝗹𝗹𝗲𝗿/𝗔𝗰𝘁𝗶𝗼𝗻 [Authorize] [ApiController] [Route("api/[controller]")] public class ProductController : ControllerBase {   [HttpGet]   public IActionResult GetProducts()   {     return Ok(new[] { "Laptop", "Mobile", "Tablet" });   } } Only authenticated users can access this endpoint. 𝗥𝗼𝗹𝗲-𝗕𝗮𝘀𝗲𝗱 𝗔𝘂𝘁𝗵𝗼𝗿𝗶𝘇𝗮𝘁𝗶𝗼𝗻 𝗘𝘅𝗮𝗺𝗽𝗹𝗲 [Authorize(Roles = "Admin")] public IActionResult DeleteUser(int id) {   // Only Admin can delete users   return Ok($"User {id} deleted"); } Roles are assigned when generating the JWT token. 𝗣𝗼𝗹𝗶𝗰𝘆-𝗕𝗮𝘀𝗲𝗱 𝗔𝘂𝘁𝗵𝗼𝗿𝗶𝘇𝗮𝘁𝗶𝗼𝗻 𝗘𝘅𝗮𝗺𝗽𝗹𝗲 builder.Services.AddAuthorization(options => {   options.AddPolicy("CanEdit", policy => policy.RequireClaim("EditPermission")); }); Then use: [Authorize(Policy = "CanEdit")] public IActionResult EditProduct() => Ok("You can edit!"); 𝗦𝘂𝗺𝗺𝗮𝗿𝘆 𝗧𝗮𝗯𝗹𝗲 Feature           Purpose                 ------------------  ------------------------------------- 𝗔𝘂𝘁𝗵𝗲𝗻𝘁𝗶𝗰𝗮𝘁𝗶𝗼𝗻    Verifies 𝘸𝘩𝘰 the user is        𝗔𝘂𝘁𝗵𝗼𝗿𝗶𝘇𝗮𝘁𝗶𝗼𝗻      Determines 𝘸𝘩𝘢𝘵 they can access    𝗝𝗪𝗧 𝗧𝗼𝗸𝗲𝗻        Securely passes user identity      𝗥𝗼𝗹𝗲-𝗯𝗮𝘀𝗲𝗱         Uses roles like Admin/User        𝗣𝗼𝗹𝗶𝗰𝘆-𝗯𝗮𝘀𝗲𝗱       Uses custom conditions (claims, etc.) 𝗜𝗻 𝘀𝗵𝗼𝗿𝘁: 𝗔𝘂𝘁𝗵𝗲𝗻𝘁𝗶𝗰𝗮𝘁𝗶𝗼𝗻 = Checking Identity 𝗔𝘂𝘁𝗵𝗼𝗿𝗶𝘇𝗮𝘁𝗶𝗼𝗻 = Checking Permission

🔐 Understanding JWT (JSON Web Token) in Modern Applications Security is at the core of every web application — and one of the most widely used mechanisms today is JWT (JSON Web Token). 🔹 What is JWT? JWT is a compact, URL-safe token format used to securely transmit information between parties. It’s commonly used for authentication and authorization in APIs and web apps. 🔹 How it works: 1️⃣ User logs in → server verifies credentials 2️⃣ Server issues a JWT token (digitally signed) 3️⃣ On every request, the client sends this token in the header (Authorization: Bearer <token>) 4️⃣ Server validates the token → grants or denies access 🔹 Structure of JWT: Header → algorithm & token type Payload → user data & claims Signature → ensures integrity & trust Example: xxxxx.yyyyy.zzzzz (Header.Payload.Signature) 🔹 Why use JWT? ✅ Stateless (no session storage required) ✅ Lightweight & fast ✅ Secure (if properly signed & stored) ✅ Scales well in distributed systems (like microservices) 🔹 Real-world use case: In a warehouse billing system 💳, JWT can secure APIs where only authenticated users can access sensitive data like invoices, payments, or shipment details. 💡 Key takeaway: JWT enables secure, stateless, and scalable authentication — a must-have for modern full-stack applications. 👉 Have you implemented JWT in your projects? What best practices do you follow for token security?

🔐 One Post for Application Safety to Remember: 6 Quick Checks (with examples) When data moves, draw the boundary. Anything that crosses a boundary = risk. For every path (form → server, API → DB, CI → runtime), run these six checks. 1️⃣ Source trustworthy? — (External = untrusted) Treat anything coming from outside your system as hostile by default. Example rule: user input, third‑party webhooks, uploaded files, and npm packages → untrusted. Short note: if it’s external, validate it, sanitize it, or deny it. 2️⃣ Is the data validated / strongly typed? Always validate at the first server boundary (not only in the client). Use typed DTOs and validators. Spring Boot: @RequestBody MyDto + @Valid + @NotBlank / custom validators. Next.js server action: validate incoming form/body with a schema (zod/Joi) before using it. 3️⃣ Does the output go straight into HTML/DOM? — (Escape!) If server data ends up in the browser DOM, escape or sanitize it. Don’t let raw user strings become HTML. Avoid dangerouslySetInnerHTML or templating hooks that inject raw HTML. If you must render HTML (rich text), sanitize with a strict whitelist sanitizer. 4️⃣ Is there server-side authorization? — (Don’t rely on client UI hiding) UI changes (hide/show buttons) are UX only. Enforce authorization on the server for every sensitive operation and resource. Check resource ownership and role/permission on the backend before acting. Principle: “client says → server verifies.” 5️⃣ For external requests: whitelist & egress control? Any server-side call to an external URL is a boundary crossing. Restrict the allowed targets and block internal IP ranges. Use an allowlist for allowed hostnames, enforce timeouts, and restrict protocols/ports. In infra, implement egress rules so the app can’t talk to internal metadata or private subnets unless explicitly allowed. 6️⃣ Can we investigate when things go wrong? — (Logs & alerts) If you can’t detect and trace an incident, you can’t respond. Log authentication failures, unexpected inputs, and outbound requests; add alerts for spike patterns. Keep request context (non-sensitive) for tracing: correlation id, user id, endpoint. Alert on abnormal rates, unusual destinations, or repeated validation errors. ✍️ Quick checklist you can recite or paste into PR reviews Source trustworthy? → Validate/type it → Escape output → Server authorize → Whitelist egress → Log & alert 🧠 Short example (pattern, not exploit detail) User submits comment → Server: validate schema → sanitize if rendering as HTML → save with ownership info → server enforces who can edit/delete → log the action and monitor spikes.

Gemini Computer View Model The Gemini 2.5 Computer Use Preview model and tool enable you to build browser control agents that interact with and automate tasks. Using screenshots, the Computer Use model can "see" a computer screen, and "act" by generating specific UI actions like mouse clicks and keyboard inputs. Similar to function calling, you need to write the client-side application code to receive and execute the Computer Use actions Ref: https://lnkd.in/gwynmXfx

Understanding Samwaad's🔥 User Authentication System(Frontend) 🤞 1) Unique User Registration: Checks for unique username and email before allowing registration. 2) Email Verification via OTP : Sends OTP to the user’s email for verification before registration.Prevents registration unless OTP verification succeeds. 3) Resend OTP : User allowed to Resend OTP only once the timer ends. 4) Conditional Button Activation: Register button is only active once all required fields are filled and verification is complete. Verify button stays disabled until all OTP digits are entered. 5) Form Validation: Validates email format using regex before sending OTP or logging in. Ensures no spaces in username. Displays error messages for missing or invalid inputs. From the frontend side, I have ensured that API calls hit the server only after proper data validation.👍 Buttons are temporarily disabled once clicked to prevent request flooding or accidental multiple submissions.👍

Everyone starts with a scraper tool. Few scale past it. Those browser extensions and plug-and-play scrapers? Perfect for one-off projects. But at enterprise scale, they collapse fast - blocked IPs, missing data, inconsistent formats, zero QA. That’s where managed web scraping steps in. It’s not just about extracting data - it’s about delivering it clean, complete, and on time. Here’s what a managed provider handles that tools can’t: ✅ Continuous monitoring for layout changes ✅ Schema validation + freshness SLAs ✅ Proxy rotation + retry logic ✅ Human QA for data consistency Because getting data is easy. Getting usable data, week after week, isn’t. 📊 Read how managed services outperform scraper tools → https://shorturl.at/sEc44 #WebScraping #DataQuality #PromptCloud

Burp Suite Deep Dive: Decoder Continuing my Burp Suite series, today I'm exploring the Decoder tool - a simple yet powerful utility that every penetration tester and security professional needs in their arsenal. What is Decoder? Decoder is Burp Suite's built-in transformation tool that allows you to encode and decode data across multiple formats. While it might seem basic at first glance, it's an essential companion during security assessments when you need to quickly interpret obfuscated data or prepare payloads. Key Features Supported Formats: URL encoding/decoding Base64 encoding/decoding HTML entity encoding/decoding ASCII Hex Octal, Binary, and Gzip compression Hash functions (MD5, SHA-1, SHA-256, etc.) Smart Text Selection: The beauty of Decoder is its integration with other Burp tools. You can right-click any data in Proxy, Repeater, or Intruder and send it directly to Decoder for transformation. Real-World Applications During penetration testing, I frequently use Decoder for: 1. Analyzing JWT Tokens - Quickly decode Base64-encoded JWT payloads to examine claims and identify potential vulnerabilities 2. Understanding URL Parameters - Decode URL-encoded parameters to reveal what data is actually being transmitted 3. Bypassing Client-Side Filters - Encode payloads in different formats to test if applications properly validate encoded input 4. Cookie Analysis - Decode Base64 or hex-encoded cookies to understand session structure and identify security issues 5. SQL Injection Payload Preparation - Encode malicious queries to bypass basic WAF rules or character filtering Pro Tips Use the chain feature to apply multiple transformations sequentially (e.g., URL decode → Base64 decode) Compare hash outputs to verify data integrity during testing Keep Decoder open in a separate tab for quick access during active assessments Use it to understand how applications obfuscate sensitive data in transit Why It Matters Many security vulnerabilities hide behind layers of encoding. Whether it's a Base64-encoded SQL injection payload, URL-encoded XSS attempt, or obfuscated API tokens, Decoder helps you see through the obfuscation and understand what's really happening under the hood. While modern browsers have built-in developer tools and there are online converters available, having Decoder integrated directly into Burp Suite streamlines your workflow and keeps sensitive testing data within your local environment.

Encrypting data can hide the details you need to debug. In this post, Tom Wheeler and Joshua Smith show how to keep sensitive fields confidential in Temporal while still seeing what happened in the Web UI and CLI. It explains when TLS is enough, when to use a Payload Codec, and how a Codec Server lets the browser decode safely. 🔐👀 Read the post: https://lnkd.in/dMpCEyhj