21. Web Application Testing Tools
21.1 How Web Testing Works: The Intercepting Proxy
Browser aani server madhe HTTP requests-responses jatat (Chapter 2 madhe shiklo). Ek intercepting proxy madhe basto aani pratyek request thambavto, dakhavto, badalu deto, mag pathavto. Hech web testing cha hriday aahe – karan browser che validation baju la sarun tumhi server la thet kahihi pathavu shakta.
Browser -> Intercepting proxy (Burp/ZAP) -> Web server
you can read and change every request here
Why this matters: a website may hide a button or check a price in JavaScript, but the real security must be on the server. With a proxy you send the request the browser never would – that is how you find broken access control, IDOR and injection.
Ravindra Bagale's Tip
Students think client-side (JavaScript) validation means security. No! A proxy bypasses it completely. Always remember: if it is not validated on the server, there is no security. In the Chapter 16 reels app you kept a server-side check – here you will see why it was needed.
Ravindra Bagale's Tip – मराठी
Students समजतात की client-side (JavaScript) validation म्हणजे security. नाही! Proxy ने तो पूर्ण बाजूला जातो. नेहमी लक्षात ठेवा: server वर validate केलं नाही, तर security नाही. Chapter 16 च्या reels app मध्ये तुम्ही server-side check ठेवला होता – इथे कळेल तो का गरजेचा होता.
Ravindra Bagale's Tip – हिंदी
Students समझते हैं कि client-side (JavaScript) validation ही security है. नहीं! Proxy से वह पूरी तरह bypass हो जाता है. हमेशा याद रखो: server पर validate नहीं किया, तो security नहीं. Chapter 16 के reels app में तुमने server-side check रखा था – यहाँ समझ आएगा कि वह क्यों ज़रूरी था.
Practice task
Draw the browser–proxy–server path in your notes and write one line: why is server-side validation the only real security? Give an example from your own reels app.
Why the proxy matters for defence
Front-end checks (hiding a button, disabling a field) are not security. The server must enforce rules. A proxy shows you the raw request so you can see what the server actually accepted.
Example
Suppose a shop site sends price=999 when you buy. In the proxy you change it to price=1. If the order succeeds at ₹1, the server trusted the client. The fix is server-side price lookup from the database, never from the request.
Where to enforce rules
Java / Spring Boot
Service layer checks ownership and price. Never trust hidden form fields.
ASP.NET Core
Authorize attributes and server-side validation.
Node.js / Express
Middleware that loads the record by id and checks req.user.id === record.ownerId.
Python / Django
LoginRequired mixin and object-level checks in the view.
PHP / Laravel
Policies and Form Requests.
Ruby / Rails
before_action authentication and authorization gems.
Everyday analogy
A hotel receptionist does not believe a guest who says "I am in the presidential suite" without checking the booking system.
Recap
- Client-side checks are for usability. Server-side checks are for security.
- Use the proxy only on apps you own.
Defender's worksheet (do this today)
- Write the lesson title and date in your notebook.
- List three systems you own (VMs, personal projects, or lab apps) where this lesson applies.
- Run one safe command or checklist item from the lesson on a lab system only.
- Paste the command and its output under an Evidence heading.
- Write one fix you would give a teammate in two sentences.
- Write one mistake students make with this topic and how to avoid it.
More real-world pictures
Indian workplace (sample data)
Suppose we are a junior analyst at Tech Mahindra supporting a client SOC. After reading this lesson you add one detection or one hardening item to the team weekly checklist, with the owner name and a due date. That is how learning becomes operations.
Global practice
Public bodies such as CERT-In (India), CISA (US) and NCSC (UK) publish advisories that map to the same ideas: patch, least privilege, logging and user awareness. Bookmark one advisory feed and read it every Monday.
Home and family
Explain this lesson to a family member in four sentences without jargon. If they can repeat the main warning back to you, you understand it well enough to teach.
Connect to earlier chapters
Parts 1 to 9 built Linux, web servers, databases and cloud pieces. This lesson only makes sense when you can point to a concrete config file, package name or architecture box from those parts. If you cannot, revisit the matching earlier chapter before you practise any tool command.
Common mistakes
- Skipping written permission just for a quick scan.
- Practising on hostel or office Wi-Fi targets without authorisation.
- Collecting tool output without writing the fix.
- Copying exploit commands onto production to verify. Verification for defenders means checking versions and patches, not firing modules.
Recap
- Evidence, fix, owner, date.
- Own lab only.
- Teach one other person the warning from this lesson.