Hacker News new | ask | show | jobs
by guard402 97 days ago
We tested this systematically and the results are more nuanced than you might expect.

We built a hotel listing page with a display:none injection ($189 listing with a hidden override to book $4,200) and tested six DOM extraction APIs via Chrome CDP. The split: innerText, Chrome Accessibility Tree, and Playwright's ARIA snapshot all filter it. textContent, innerHTML, and direct querySelector don't.

Then we audited the source code of all four major browser MCP tools: chrome-devtools-mcp (Google), playwright-mcp (Microsoft), chrome-cdp-skill, and puppeteer-mcp. Every single one defaults to a safe extraction method — accessibility tree or innerText. That's the good news.

The bad news: three out of four expose evaluate_script or eval commands that let the agent run arbitrary JS in the page context. When the accessibility tree doesn't return enough text (it often only gives headings and buttons), the agent's natural next step is textContent or innerHTML via eval. This is even shown as an example in the chrome-devtools-mcp docs.

Also: display:none is just the simplest technique. We tested opacity:0, font-size:0, and position:absolute left:-9999px — all three bypass even the safe defaults because the elements are technically "rendered" and accessible to screen readers. A determined attacker who knows you're using the accessibility tree can trivially switch to opacity-based hiding.