Skip to content
OPS // KITitspentest.sh

R-CHR

Chrome DevTools

Chrome's built-in developer tools for inspecting network traffic, storage, and JavaScript execution live in the browser.

Official siteBack to catalog

OVERVIEW

Chrome DevTools (developer.chrome.com/docs/devtools) is the suite of inspection panels built into every Chrome install — Elements, Console, Sources, Network, Application, and more — and while it's a general web-development tool, several panels are part of the daily pentesting toolkit: Network shows every request/response with full headers and timing, Application exposes cookies (including HttpOnly/Secure/SameSite flags), localStorage, sessionStorage, and service workers, and Sources lets you set breakpoints and step through minified or obfuscated client-side JavaScript.

It requires no installation or proxy configuration, which makes it the fastest way to answer a client-side question — what exactly did that request send, is this cookie missing a security flag, what does this script do when it runs — before deciding whether the finding is worth escalating to a heavier tool such as Burp Suite (see the separate entry on this site) or DOM Invader for a full source-to-sink taint trace.

USE CASES

Practical use cases

  • 01

    Inspecting the Network panel to see exact request/response headers, timing, and payloads without a proxy in the loop.

  • 02

    Checking the Application panel for missing cookie flags (Secure, HttpOnly, SameSite) or sensitive data left in localStorage/sessionStorage.

  • 03

    Stepping through client-side JavaScript in Sources to understand obfuscated logic or find a hardcoded secret/endpoint.

  • 04

    Using the Console to manipulate DOM state, trigger client-side functions directly, or test a quick payload before scripting it elsewhere.

QUICK START

For any client-side question during web testing — what a request actually sent, what a cookie's flags are, what a script does — before reaching for a heavier tool.

  1. Open DevTools (F12 or right-click > Inspect) while browsing the in-scope target normally.
  2. Use the Network panel, with 'Preserve log' enabled, to capture requests across page navigations.
  3. Check the Application panel for cookies, storage, and service workers tied to the current origin.
  4. Use Sources to set breakpoints on suspicious client-side code, or the Console to probe and manipulate state directly.

BEFORE YOU RUN IT

What to check before running it

It only shows what runs in this browser instance — server-side logic, other clients, and native mobile apps need separate coverage (Burp Suite, mobile-specific tooling).

Modifying client-side JavaScript or storage in DevTools only changes local browser state; it doesn't bypass server-side validation, so confirm any client-side bypass actually reaches the server unguarded.

DevTools protocol access (chrome://inspect, remote debugging) can itself be a finding if left exposed on a production build — note it separately from manual testing use.

KEEP EXPLORING

View the whole phase →