Frontend Interview Essentials: Communication Concepts

This section covers fundamental concepts in frontend development related to communication, essential for interviews in 2023. It delves into server-side rendering (SSR), client-side rendering (CSR), HTTP protocols, caching mechanisms, asynchronous operations, cross-origin resource sharing (CORS), and web security.

Server-Side Rendering (SSR) vs. Client-Side Rendering (CSR)

Basic Concepts

Server-Side Rendering (SSR): The process where the server generates the HTML structure of a page and sends it to the browser, which then binds states and events to make it fully interactive. This is often implemented using Node.js on the backend with frameworks like React or Vue, and it's beneficial for SEO.

Client-Side Rendering (CSR): The process where JavaScript on the client (browser) handles the assembly of the page's DOM structure and data, which is then rendered by the browser. Single Page Applications (SPAs) typically employ CSR, updating content dynamically without full page reloads.

Search Engine Optimization (SEO): The practice of optimizing websites to improve their visibility and ranking in search engine results.

SSR Advantages and Disadvantages

  • Frontend Effort Reduction: The browser directly renders the pre-built HTML from the server, reducing client-side processing time.
  • SEO Benefits: Search engine crawlers can more easily access and index content from fully rendered HTML pages.
  • Backend Resource Consumption: Server resources are utilized for template parsing and HTML generation.
  • Coupling: Can hinder frontend-backend separation, potentially impacting development efficiency.
  • Caching: Static files can be generated on the backend to reduce database load, especially effective for pages with infrequent data changes.

CSR Advantages and Disadvantages

CSR is well-suited for highly interactive applications. SSR excels in scenarios prioritizing SEO, faster initial page loads, and overall performance.

Isomorphic Applications: A hybrid approach combining both SSR and CSR can leverage the strengths of each, rendering certain pages server-side and others client-side.

Browser Request Lifecycle: From URL Input to Page Rendering

The process begins when a browser receives a URL. It first checks local caches. If the resource isn't cached, it proceeds to DNS resolution to find the IP address, establishes a TCP connection using a three-way handshake, sends an HTTP request (including headers and potentially a body), receives the HTTP response (with status codes and headers), processes the response based on its content type, and finally renders the page. The TCP connection is then closed via a four-way handshake.

DNS Resolution

The Domain Name System (DNS) translates human-readable domain names into machine-readable IP addresses. This process involves querying DNS cache servers. DNS is typically an application-layer protocol running over UDP on port 53.

OSI Model and TCP/IP Protocol

Understanding the layered architecture of network communication is crucial. The OSI model provides a conceptual framework with seven layers (Physical, Data Link, Network, Transport, Session, Presentation, Application), while the TCP/IP model, more practically implemented, typically consists of four layers (Network Interface, Internet, Transport, Application).

HTTP Protocol

HTTP (Hypertext Transfer Protocol) is the foundation for data communication on the World Wide Web, built on TCP/IP. It's a stateless protocol, meaning each request is treated independently without inherent memory of past interactions.

HTTP vs. HTTPS

HTTPS (HTTP Secure) is an encrypted version of HTTP, utilizing SSL/TLS protocols for secure communication. Key differences include:

  • URL Scheme: HTTP uses http://, HTTPS uses https://.
  • Security: HTTPS encrypts data in transit, while HTTP transmits it in plain text.
  • Ports: HTTP typically uses port 80, HTTPS uses port 443.
  • Layer: HTTP operates at the Application Layer; SSL/TLS (part of HTTPS) operates at the Transport Layer.

HTTPS combines HTTP with SSL/TLS to encrypt data using symmetric encryption for efficiency and asymmetric encryption for secure key exchange.

Common HTTP Request Methods

  • GET: Retrieves data identified by a URI.
  • POST: Submits data to be processed (e.g., creating a resource).
  • HEAD: Similar to GET but retrieves only the headers, not the body.
  • PUT: Updates a resource at a specific URI.
  • DELETE: Removes a resource at a specific URI.
  • OPTIONS: Queries the server about the communication options available for the target resource.

GET vs. POST

  • Similarities: Both use TCP connections.
  • Differences:
    • Data Transmission: GET typically sends data in the URL, while POST sends it in the request body.
    • Request Packetization: GET usually results in one TCP packet; POST can result in two (header first, then body, often with a '100 Continue' response in between).
    • Caching: GET requests are typically cached by browsers; POST requests are not by default.
    • History: GET parameters are visible in browser history; POST parameters are not.
    • Length Limits: GET has URL length limitations; POST does not.
    • Security: POST is generally considered more secure for sensitive data as parameters are not exposed in the URL.

Here's an example of a POST request with JSON data using fetch:


fetch('/api/resource', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json'
  },
  body: JSON.stringify(requestData) // requestData is a JavaScript object
})
.then(response => response.json())
.then(jsonData => console.log('Success:', jsonData))
.catch(error => console.error('Error:', error));

POST Content-Type Encoding

The Content-Type header specifies how the request body is encoded. Common types for POST requests include:

  • application/x-www-form-urlencoded (default for HTML forms)
  • multipart/form-data (for file uploads)
  • application/json (common for APIs)
  • text/xml

HTTP Message Structure

HTTP messages consist of a start-line (request line or status line), headers, and an optional body.

  • Request Message: Start-line (Method, URI, HTTP Version), Headers (General, Request, Entity), Body (for POST).
  • Response Message: Start-line (HTTP Version, Status Code), Headers (General, Response, Entity), Body.

HTTP Versions

HTTP has evolved significantly:

  • HTTP/1.0: Used short connections, inefficient for multiple resources.
  • HTTP/1.1: Introduced persistent connections (Keep-Alive), pipelining, and chunked transfer encoding, improving efficiency.
  • HTTP/2: Uses binary framing, multiplexing (concurrent requests over a single connection), header compression, and server push for further performance gains.
  • HTTP/3: Builds upon HTTP/2, utilizing the QUIC protocol (over UDP) to reduce latency and improve congestion control, including features like 0-RTT hendshakes.

HTTP Status Codes

Status codes indicate the outcome of an HTTP request:

  • 1xx (Informational): Request received, continuing process.
  • 2xx (Success): The action was successfully received, understood, and accepted. (e.g., 200 OK, 204 No Content)
  • 3xx (Redirection): Further action needs to be taken by the user agent. (e.g., 301 Moved Permanently, 302 Found, 304 Not Modified)
  • 4xx (Client Error): The request contains bad syntax or cannot be fulfilled. (e.g., 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found)
  • 5xx (Server Error): The server failed to fulfill an apparently valid request. (e.g., 500 Internal Server Error, 502 Bad Gateway, 504 Gateway Timeout)

UDP vs. TCP

  • UDP (User Datagram Protocol): Connectionless, unreliable, faster, suitable for real-time applications (streaming, gaming).
  • TCP (Transmission Control Protocol): Connection-oriented, reliable, ensures ordered delivery, suitable for data integrity-critical applications (file transfer, web browsing).

TCP Handshake and Termination

  • Three-Way Handshake: Establishes a reliable TCP connection (SYN, SYN-ACK, ACK).
  • Four-Way Handshake: Terminates a TCP connection (FIN, ACK, FIN, ACK).
  • Sliding Window: A flow control mechanism to prevent the sender from overwhelming the receiver.
  • Congestion Control: Algorithms to manage network congestion and optimize throughput.
  • Keep-Alive: Persistent connections can be maintained to reduce the overhead of establishing new connections for subsequent requests.

TCP Packet Loss (Sticky Packets): UDP has message boundaries, preventing sticky packets. TCP, being a stream-based protocol, can lead to sticky packets (multiple packets merging) or fragmentation (a single packet split), requiring application-level logic for reassembly.

Caching

Caching improves performance by storing frequently accessed data locally.

Types of Cache

  • HTTP Caching: Governed by HTTP headers.
    • Mandatory Caching (Cache-Control, Expires): Resources are served directly from the cache if valid based on headers like Expires or Cache-Control directives (e.g., max-age). Cache-Control has higher precedence.
    • Negotiation Caching (ETag, Last-Modified): If mandatory caching fails or expires, the browser sends conditional requests using headers like If-None-Match (for ETag) or If-Modified-Since (for Last-Modified). The server responds with 304 Not Modified if the resource hasn't changed, allowing the client to use its cached copy, or 200 OK with the new resource if it has changed.
  • Browser Cache Storage:
    • Memory Cache: Very fast, but data is lost when the process (tab/browser) closes. Often used for parsed scripts.
    • Disk Cache: Slower than memory cache but persistent across sessions. Used for resources like CSS.

Browser cache lookup order is typically Memory Cache first, then Disk Cache.

Local Storage Mechanisms

Web applications use various methods to store data client-side:

Cookie

Small pieces of data sent from a website and stored on the user's computer by the web browser while the user is browsing. They are automatically sent back to the server with subsequent requests to the same domain. Used for session management and tracking.

  • Attributes: Name, Value, Expires/Max-Age, Path, Domain, Secure, HttpOnly.
  • Scope: Tied to a domain and path.
  • Security: HttpOnly prevents JavaScript access, mitigating some XSS risks. Sensitive data should not be stored directly in cookies.

Session

Server-side storage for user-specific data during a session. A session ID is typically stored in a cookie on the client to link requests to the correct server-side session data.

  • Storage: Server-side.
  • Security: More secure then client-side storage as sensitive data isn't exposed directly.
  • Dependency: Relies on cookies (or other mechanisms) to transmit the session ID.

Cookie vs. localStorage vs. sessionStorage

  • Transmission: Cookies are sent with every HTTP request; localStorage and sessionStorage are not.
  • Storage Capacity: Cookies are limited (around 4KB); localStorage and sessionStorage offer more space.
  • Expiration:
    • localStorage: Persistent until explicitly cleared.
    • sessionStorage: Cleared when the browser tab/window is closed.
    • Cookies: Can be session-based (expire on browser close) or persistent (expire at a set date/time).
  • Scope:
    • sessionStorage: Scoped to the browser tab/window.
    • localStorage and Cookies (with appropriate domain/path): Shared across tabs/windows from the same origin.

Tokens and JWT

Authentication vs. Authorization

  • Authentication: Verifying the identity of a user (e.g., username/password).
  • Authorization: Determining what actions an authenticated user is permitted to perform (e.g., granting app permissions).

Credentials

A medium (like a token) used to prove identity for authentication and authorization.

Token (Access Token)

A credential used to access protected resources (APIs). A simple token might include user ID, timestamp, and a signature.

  • Characteristics: Server statelessness, scalability, mobile support, security.
  • Flow: User logs in -> Server issues Token -> Client stores Token -> Client sends Token with requests -> Server validates Token.

Refresh Token

Used to obtain new access tokens when the current ones expire, reducing the need for users to re-login frequently. Refresh tokens are typically stored securely on the server.

Token vs. Session

  • Session: Server-side stateful mechanism.
  • Token: Stateless credential. Allows servers to remain stateless, improving scalability. JWT (JSON Web Token) is a common token format.
  • Security: Tokens with signatures offer protection against replay attacks and eavesdropping. Sessions rely on secure transport (like HTTPS).
  • Use Cases: Tokens are preferred for mobile apps and scenarios requiring API sharing due to their stateless nature and ability to bypass same-origin policy constraints.

JSON Web Token (JWT)

A compact, URL-safe means of representing claims to be transferred between two parties. It consists of three parts: Header, Payload, and Signature, encoded in Base64 URL format.

  • Header: Contains metadata like the signing algorithm (e.g., HS256) and token type (JWT).
  • Payload: Contains claims (information about the user and additional data). Registered claims like iss (issuer), exp (expiration time), sub (subject) are standard.
  • Signature: Used to verify the sender and ensure the message wasn't altered.
  • Transmission: Typically sent in the Authorization header as a Bearer token.
  • Pros: Self-contained, stateless, good for cross-origin communication.
  • Cons: Tokens can become large, and revoked tokens remain valid until expiration unless additional server-side logic is implemented.

Data Exchange Formats

XML

Extensible Markup Language (XML) is a markup language that defines rules for encoding documents in a format that is both human-readable and machine-readable. It's used for data interchange, configuration files, and more.

JSX

JavaScript XML is a syntax extension for JavaScript, often used with React. It allows writing HTML-like structures within JavaScript code, which is then transpiled by tools like Babel into standard JavaScript.


// JSX syntax
const element = (
  <h2 title="hello">
    Hello World!
    <span>!!!</span>
  </h2>
);

// Equivalent standard JavaScript using React.createElement
// const element = React.createElement(
//   'h2',
//   { title: 'hello' },
//   'Hello World!',
//   React.createElement('span', null, '!!!')
// );

Babel

A JavaScript compiler that transforms modern JavaScript code (ES6+) and JSX into backward-compatible versions that can be understood by older browsers.

JSON

JavaScript Object Notation is a lightweight, text-based, human-readable data interchange format. It's widely used for transmitting data between a server and a web application.

  • Syntax: Uses key-value pairs ("key": value), arrays ([]), and objects ({}).
  • Parsing/Stringifying: JavaScript provides JSON.parse() to convert JSSON strings into JavaScript objects and JSON.stringify() to convert JavaScript objects into JSON strings.

const jsonString = '{"name": "Alice", "age": 30, "isStudent": false}';
const jsObject = JSON.parse(jsonString);

const anotherObject = { city: "New York", zip: 10001 };
const anotherJsonString = JSON.stringify(anotherObject);

Asynchronous Operations

Asynchronous operations allow JavaScript to perform tasks without blocking the main thread, ensuring a responsive user interface.

Web Workers

Web Workers enable running JavaScript in background threads, separate from the main execution thread. This prevents long-running scripts from freezing the UI.

// main.js
const myWorker = new Worker('worker.js');
myWorker.postMessage('Start processing');

myWorker.onmessage = function(event) {
  console.log('Message from worker:', event.data);
};

// worker.js
self.onmessage = function(event) {
  console.log('Message received in worker:', event.data);
  // Perform some heavy computation
  const result = 'Processing complete';
  self.postMessage(result);
};
myWorker.terminate(); // To stop the worker

AJAX

Asynchronous JavaScript and XML (AJAX) is a technique for building interactive web applications by allowing asynchronous communication with the server without full page reloads.

Native AJAX (XMLHttpRequest)


const xhr = new XMLHttpRequest();
xhr.open('GET', '/api/data', true); // Method, URL, Async

xhr.onreadystatechange = function() {
  if (xhr.readyState === 4) { // Request finished and response is ready
    if (xhr.status === 200) { // Success
      console.log(xhr.responseText);
      const data = JSON.parse(xhr.responseText);
      // Process data
    } else {
      console.error('Request failed:', xhr.status);
    }
  }
};

xhr.setRequestHeader('Content-Type', 'application/json'); // For POST/PUT
xhr.send(JSON.stringify(requestData)); // Send data for POST/PUT

Axios

A popular, Promise-based HTTP client for browsers and Node.js, offering features like request/response interception, automatic JSON transformation, and cancellation.


import axios from 'axios';

// GET request
axios.get('/api/users', { params: { id: 123 } })
  .then(response => {
    console.log(response.data); // Response data
  })
  .catch(error => {
    console.error('Error fetching users:', error);
  });

// POST request
axios.post('/api/users', {
  firstName: 'John',
  lastName: 'Doe'
})
.then(response => {
  console.log(response.data);
})
.catch(error => {
  console.error('Error creating user:', error);
});

setTimeout() and setInterval()

  • setTimeout(callback, delay): Executes a function once after a specified delay.
  • setInterval(callback, delay): Executes a function repeatedly at a specified interval.

Both return an ID that can be used with clearTimeout() or clearInterval() to cancel the timer.


// Using setTimeout for a countdown
let countdown = 10;
const timerId = setTimeout(function tick() {
  console.log(countdown);
  countdown--;
  if (countdown >= 0) {
    setTimeout(tick, 1000); // Schedule the next tick
  } else {
    console.log("Blast off!");
  }
}, 1000);

// To cancel: clearTimeout(timerId);

// Using setInterval
let counter = 0;
const intervalId = setInterval(() => {
  console.log('Tick:', counter++);
  if (counter >= 5) {
    clearInterval(intervalId); // Stop the interval
    console.log('Interval stopped.');
  }
}, 1000);

Key Differences: setTimeout executes once, while setInterval executes repeatedly. The delay in setInterval includes the execution time of the callback, potentially leading to drift if the callback takes too long. setTimeout provides a more predictable delay between executions.

Promise

Promises are objects representing the eventual completion (or failure) of an asynchronous operation and its resulting value. They help manage asynchronous code more cleanly than callbacks, avoiding "callback hell."

  • States: Pending, Fulfilled, Rejected.
  • Methods:
    • .then(onFulfilled, onRejected): Handles successful resolution or rejection.
    • .catch(onRejected): Shorthand for handling rejections.
    • .finally(onFinally): Executes regardless of the promise's outcome.
    • Static methods: Promise.all(), Promise.race(), Promise.resolve(), Promise.reject().

function fetchData(url) {
  return new Promise((resolve, reject) => {
    fetch(url)
      .then(response => {
        if (!response.ok) {
          throw new Error(`HTTP error! status: ${response.status}`);
        }
        return response.json();
      })
      .then(data => resolve(data))
      .catch(error => reject(error));
  });
}

fetchData('/api/users')
  .then(users => console.log('Users:', users))
  .catch(error => console.error('Failed to fetch users:', error));

// Handling multiple promises with Promise.all
Promise.all([
  fetchData('/api/users'),
  fetchData('/api/posts')
])
.then(([users, posts]) => {
  console.log('Users:', users);
  console.log('Posts:', posts);
})
.catch(error => console.error('One of the requests failed:', error));

// To get results even if some promises reject:
Promise.all(promises.map(p => p.catch(e => e))) // Map each promise to one that resolves with its error
.then(results => {
  // results will contain resolved values or error objects
  console.log(results);
});

fetch() API

The fetch() API provides a modern, Promise-based interface for making network requests. It's a more powerful and flexible replacement for XMLHttpRequest.


fetch('/api/resource', {
  method: 'GET', // or 'POST', 'PUT', 'DELETE', etc.
  headers: {
    'Accept': 'application/json'
  }
})
.then(response => {
  if (!response.ok) {
    throw new Error(`HTTP error! status: ${response.status}`);
  }
  return response.json(); // Or response.text(), response.blob(), etc.
})
.then(data => {
  console.log('Data received:', data);
})
.catch(error => {
  console.error('Fetch error:', error);
});

async/await

Syntactic sugar built on top of Promises and Generators, allowing asynchronous code to be written in a more synchronous-looking style, improving readability.


async function processData() {
  try {
    const userData = await fetch('/api/user').then(res => res.json());
    console.log('User:', userData);

    const postsData = await fetch('/api/posts').then(res => res.json());
    console.log('Posts:', postsData);

    // If user and posts data are independent, run them in parallel:
    // const [userData, postsData] = await Promise.all([
    //   fetch('/api/user').then(res => res.json()),
    //   fetch('/api/posts').then(res => res.json())
    // ]);
    // console.log('User:', userData, 'Posts:', postsData);

  } catch (error) {
    console.error('An error occurred:', error);
  }
}

processData();

Cross-Origin Communication

The Same-Origin Policy (SOP) restricts web pages from making requests to a different domain than the one the page originated from. Cross-Origin Resource Sharing (CORS) is a mechanism that allows servers to indicate which origins are permitted to access their resources.

JSONP

A technique that leverages the ability of <script> tags to load resources from different domains. It involves dynamically creating a script tag and appending a callback function name to the URL. The server wraps the JSON response in a call to this callback function.

  • Limitation: Only supports GET requests.
// Client-side (simplified)
function jsonpRequest(url, callbackName, params) {
  return new Promise((resolve, reject) => {
    const script = document.createElement('script');
    window[callbackName] = (data) => {
      resolve(data);
      document.body.removeChild(script);
    };

    let paramString = Object.keys(params)
      .map(key => `${key}=${encodeURIComponent(params[key])}`)
      .join('&');
    script.src = `${url}?${paramString}&callback=${callbackName}`;
    document.body.appendChild(script);
  });
}

jsonpRequest('/api/data', 'handleData', { query: 'example' })
  .then(data => console.log('JSONP data:', data))
  .catch(error => console.error('JSONP error:', error));

Cross-Origin Resource Sharing (CORS)

A standard that enables servers to specify which origins are allowed to access their resources via HTTP headers. It supports various request methods and headers.

  • Simple Requests: GET, HEAD, POST (with specific Content-Types).
  • Preflighted Requests: For other methods (PUT, DELETE) or Content-Types, the browser sends an OPTIONS request first to check permissions.
  • Server Configuration: Requires setting response headers like Access-Control-Allow-Origin, Access-Control-Allow-Methods, Access-Control-Allow-Headers.
  • Credentials: To send cookies or authentication headers, Access-Control-Allow-Credentials: true must be set on the server, and xhr.withCredentials = true; on the client.

// Server-side (Node.js with Express example)
const cors = require('cors');
const express = require('express');
const app = express();

app.use(cors({
  origin: 'http://localhost:3000', // Allow requests from this origin
  methods: ['GET', 'POST', 'PUT', 'DELETE', 'OPTIONS'],
  allowedHeaders: ['Content-Type', 'Authorization'],
  credentials: true // Allow cookies/credentials
}));

app.get('/api/resource', (req, res) => {
  res.json({ message: 'Data from CORS-enabled API' });
});

app.listen(8000, () => console.log('CORS-enabled API server listening on port 8000'));

postMessage()

An HTML5 API for secure cross-origin communication between windows, frames, or iframes. It allows sending messages asynchronously.

// Sender window (e.g., parent frame)
const iframe = document.getElementById('myIframe');
iframe.contentWindow.postMessage('Hello from parent!', 'http://other-domain.com');

// Receiver window (e.g., iframe content)
window.addEventListener('message', (event) => {
  if (event.origin !== 'http://parent-domain.com') return; // Security check
  console.log('Message received:', event.data);
  event.source.postMessage('Response from iframe!', 'http://parent-domain.com');
});

Proxy Servers (Nginx)

A proxy server acts as an intermediary for requests from clients seeking resources from other servers. Nginx can be configured as a reverse proxy to handle cross-origin requests transparently by forwarding requests to the appropriate backend server.

Forward Proxy: Acts on behalf of clients to access external resources, hiding client identity.

Reverse Proxy: Acts on behalf of servers, receiving client requests and forwarding them to internal servers, providing load balancing and security.


# Nginx configuration example for reverse proxy
server {
    listen 80;
    server_name localhost;

    location /api/ {
        proxy_pass http://backend-api-server:8000/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        # Add CORS headers if the backend doesn't handle them
        add_header 'Access-Control-Allow-Origin' 'http://localhost:3000';
        add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';
    }

    location / {
        root /usr/share/nginx/html; # Serve frontend static files
        try_files $uri $uri/ /index.html;
    }
}

WebSocket Protocol

WebSocket provides a full-duplex communication channel over a single, long-lived TCP connection. It allows real-time, bidirectional data transfer between a client and server.

// Client-side
const socket = new WebSocket('ws://localhost:3000');

socket.onopen = () => {
  console.log('WebSocket connection opened');
  socket.send('Hello Server!');
};

socket.onmessage = (event) => {
  console.log('Message from server:', event.data);
};

socket.onerror = (error) => {
  console.error('WebSocket error:', error);
};

socket.onclose = () => {
  console.log('WebSocket connection closed');
};

// Server-side (using 'ws' library)
const WebSocket = require('ws');
const wss = new WebSocket.Server({ port: 3000 });

wss.on('connection', (ws) => {
  console.log('Client connected');
  ws.on('message', (message) => {
    console.log('Received:', message);
    ws.send('Hello Client!');
  });
  ws.on('close', () => {
    console.log('Client disconnected');
  });
});

Web Security

XSS (Cross-Site Scripting) Attacks

Occurs when malicious scripts are injected into trusted websites. These scripts can steal sensitive user information (cookies, session tokens) or perform actions on behalf of the user.

  • Prevention: Input validation, output encoding (e.g., using encodeURIComponent), using frameworks that sanitize HTML, avoiding innerHTML with untrusted content.

CSRF (Cross-Site Request Forgery) Attacks

Tricks a logged-in user's browser into sending an unintended, malicious request to a web application they are authenticated with. The application performs the action as if the user intended it.

  • Prevention: Anti-CSRF tokens (unique, unpredictable values submitted with requests), CAPTCHAs, checking the Origin or Referer headers.

SQL Injection Attacks

Involves injecting malicious SQL code into input fields or URL parameters, allowing attackers to manipulate the database.

  • Prevention: Parameterized queries (prepared statements), input validation, escaping special characters.

DDoS (Distributed Denial of Service) Attacks

Overwhelms a server or network resource with a flood of traffic from multiple compromised systems, making the service unavailable to legitimate users.

  • Prevention: Rate limiting, IP blocking, firewalls, Content Delivery Networks (CDNs), traffic analysis.

Tags: HTTP HTTPS Web Security Ajax Fetch API

Posted on Wed, 05 Aug 2026 16:50:20 +0000 by hernan

Hot Tags

©2026 Freaks City