Skip to content

fix: tighten press/click.*hold regex to prevent false positives on normal page content - #1649

Merged
ssilare-adobe merged 1 commit into
mainfrom
fix/bot-blocker-press-hold-false-positive
Jun 4, 2026
Merged

fix: tighten press/click.*hold regex to prevent false positives on normal page content#1649
ssilare-adobe merged 1 commit into
mainfrom
fix/bot-blocker-press-hold-false-positive

Conversation

@ssilare-adobe

Copy link
Copy Markdown
Contributor

Summary

  • CHALLENGE_PATTERNS.general contained /press.*hold/i and /click.*hold/i with unbounded .* wildcards
  • On sites with minified HTML, these matched across thousands of characters — e.g. blood pressure monitor (index 281,995) to placeholder graphic (index 291,537) on athenahealth.com — causing a false-positive crawlable: false result despite the site returning HTTP 200 with no challenge page
  • Tightened both patterns to require the words to be adjacent (with optional "and"): /press\s+(and\s+)?hold/i — matching real challenge copy like "Press and hold the button" while rejecting incidental word proximity

Changes

  • src/bot-blocker-detect/bot-blocker-detect.js: narrow press.*hold and click.*hold patterns
  • test/bot-blocker-detect/bot-blocker-detect.test.js: add regression test covering blood pressure + placeholder content

Test plan

  • All 1155 existing tests continue to pass
  • New regression test does not false-positive on "pressure" and "placeholder" in normal page content passes
  • Real "Press and hold" and "Click and hold" challenge strings still detected correctly

@ssilare-adobe
ssilare-adobe requested a review from MysticatBot June 4, 2026 05:31

@MysticatBot MysticatBot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @ssilare-adobe,

Strengths

  • bot-blocker-detect.js:106-107: The fix directly addresses the root cause. Replacing unbounded .* with \s+(and\s+)? eliminates catastrophic matching across thousands of characters of minified HTML while preserving detection of real challenge copy. The new patterns are also free of ReDoS risk - no nested quantifiers or overlapping alternations, and worst-case backtracking is linear.
  • bot-blocker-detect.test.js:962-975: The regression test reproduces the exact failure scenario from the bug report ("pressure" + "placeholder" proximity) with realistic HTML content and good behavior-level assertions checking both crawlable and type.
  • Change discipline is excellent. Two patterns changed, one test added, nothing else touched. The PR body explains the mechanism of failure thoroughly with concrete index positions from a real site.
  • Follows all documented project conventions: test mirrors src structure, uses describe/it with expect assertions, and the commit message follows conventional commits format.

Issues

Minor (Nice to Have)

  1. bot-blocker-detect.js:106-107: The patterns lack word boundaries, so they can match inside compound words. For example, /press\s+(and\s+)?hold/i would match in content like "Express Holdings" - "press" at the tail of "Express", whitespace, then "hold" at the head of "Holdings". Adding \b at both edges (/\bpress\s+(and\s+)?hold\b/i and /\bclick\s+(and\s+)?hold\b/i) would close this. This is Minor because the false-positive surface is dramatically smaller than before, and the practical likelihood is low.

  2. bot-blocker-detect.test.js: The new regression test only exercises the press...hold false-positive path. A symmetric negative test for click...hold (e.g., HTML containing "clickbait" near "household") would make future regressions on either pattern independently detectable.

Recommendations

  • The broader pattern (a flat array of regexes run against full HTML documents) has a structural fragility: any regex with unbounded wildcards is one minified page away from the same class of false positive. Worth considering in a future effort: a lightweight validation harness that runs each pattern against a corpus of known-good pages as a CI gate, catching overly broad patterns before they ship.

Assessment

Ready to merge? Yes
Reasoning: This is a well-scoped, minimal fix to a real production false-positive scenario. The tightened patterns correctly model the intended detection semantics, CI passes with all 1155 tests green, and no security or architectural concerns exist.


Skill: pr-review | Model: us.anthropic.claude-opus-4-6-v1[1m] | Duration: 0m 33s | Cost: $2.26 | Commit: 261f994f1820ac1291696b2f1f6a023dcb8c994e
If this code review was useful, please react with 👍. Otherwise, react with 👎.

@MysticatBot MysticatBot added the ai-reviewed Reviewed by AI label Jun 4, 2026
@ssilare-adobe
ssilare-adobe merged commit 96e9c83 into main Jun 4, 2026
6 checks passed
@ssilare-adobe
ssilare-adobe deleted the fix/bot-blocker-press-hold-false-positive branch June 4, 2026 05:39
solaris007 pushed a commit that referenced this pull request Jun 4, 2026
## [@adobe/spacecat-shared-utils-v1.116.6](https://github.com/adobe/spacecat-shared/compare/@adobe/spacecat-shared-utils-v1.116.5...@adobe/spacecat-shared-utils-v1.116.6) (2026-06-04)

### Bug Fixes

* tighten press/click.*hold regex to prevent false positives on normal page content ([#1649](#1649)) ([96e9c83](96e9c83))
@solaris007

Copy link
Copy Markdown
Member

🎉 This PR is included in version @adobe/spacecat-shared-utils-v1.116.6 🎉

The release is available on:

Your semantic-release bot 📦🚀

ssilare-adobe added a commit to adobe/spacecat-api-service that referenced this pull request Jun 4, 2026
## Summary

- Bumps `@adobe/spacecat-shared-utils` from `1.115.4` to `1.116.6`
- `@adobe/spacecat-shared-tokowaka-client` is already at `1.19.0`
(landed in #2552)

## Changes

- `package.json`: `@adobe/spacecat-shared-utils` `1.115.4` → `1.116.6`

Notable in `1.116.6`: tightens the `/press.*hold/` and `/click.*hold/`
regexes in `detectBotBlocker` to require adjacent words, preventing
false-positive bot-block detections on normal page content (e.g.
athenahealth.com). See adobe/spacecat-shared#1649.

## Test plan

- [ ] CI passes
- [ ] No regression in bot-blocker detection
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants