Infra 4 – Imperva WAF

Imperva Web Application Firewall (WAF) is a cloud-based security service that protects your web applications from:

• OWASP Top 10 threats (SQLi, XSS, etc.)
• DDoS attacks
• Bot traffic
• Zero-day vulnerabilities

It acts as a reverse proxy: incoming HTTP/HTTPS traffic is first routed to Imperva’s network, where it is filtered and scrubbed before being forwarded to your application.

[Client] → [Imperva WAF (cloud)] → [Azure Traffic Manager] → [App endpoints (App Gateway, VM, etc.)]

Client (User) → Customer
Just like a customer wants to dine at a restaurant, the user wants to access your application.

Imperva WAF → Security Guard at the Main Gate
Before anyone enters, the security guard checks for threats (like a hacker or a bot) and only lets in safe guests.

Azure Traffic Manager → Receptionist at the Front Desk
The receptionist decides which restaurant branch (region/backend) is best for the guest, based on distance, speed, or availability.

Azure Application Gateway → Restaurant Manager Inside the Branch ask how many members
Once inside a branch, the manager decides which kitchen handles which order (based on URL path, SSL, etc.), ensuring smooth service.

Backend App Servers → Kitchen & Chefs
The chefs (backend servers) prepare the requested dishes (web pages, APIs) and send them back to the guest.

A user visits a restaurant — this represents someone accessing your application.

At the entrance, a security guard (Imperva WAF) stops people who look suspicious — like those who are drunk or trying to cause trouble. In technical terms, this means blocking hackers or malicious traffic.

If the user is safe, they meet the receptionist (Azure Traffic Manager). The receptionist asks what kind of food the person wants — like veg or non-veg — and based on their answer (like user’s location or preferences), they are sent to the appropriate restaurant branch. This means routing traffic to the best region or backend.

Once the user reaches the branch, the restaurant manager (Azure Application Gateway) welcomes them and asks exactly what they want — like dosa, biryani, or pizza. This means the gateway inspects the request (URL, protocol, etc.) and forwards it to the correct backend service.

Finally, the chef (backend app server) prepares the dish — i.e., processes the request and sends back the required data (like a video, image, or webpage) to the user.

Step-by-Step Walkthrough

🧍‍♂️ Step 1: Customer Comes to Your Brand’s Entrance

• The user types www.example.com
• This DNS points to Imperva WAF (security layer)
  
  
  Step 2: Imperva WAF (Security Guard)
  • Checks the request for:
    • Malicious traffic (SQL injection, XSS)
    • Bot traffic
    • Rate limiting
  • Only safe traffic is allowed through.
  ✅ Legit user → Forwarded
  ❌ Hacker/bot → Blocked

Step 3: Traffic Manager (Receptionist)

• Decides which restaurant branch (region) should serve the customer
  • Based on proximity (Geo-routing)
  • Health of the location (Performance)
  • Traffic load (Priority)

E.g.,
US user → Sent to US branch
Europe user → Sent to EU branch

🏢 Step 4: Application Gateway (Restaurant Manager)

• Receives the request at that branch
• Handles:
  • SSL offloading (unpacking encrypted orders)
  • URL path routing (dining area vs. delivery kitchen)
  • WAF (Azure native) if enabled
• Forwards traffic to the correct kitchen

👨‍🍳 Step 5: Backend App Servers (Kitchen)

• Prepare the requested content (HTML, APIs, images)
• Send it back through:
  • App Gateway
  • Traffic Manager
  • WAF
• Delivered to the customer (browser)