[Search] Oversized query string accepted silently — no character limit enforced, no user feedback

[VadimLindebaum]

Describe the bug

The Spotify Web Player search bar accepts arbitrarily long input strings with no visible character limit,
no validation warning, and no user-facing error message. When a query exceeding ~200 characters is
submitted, one of two silent failure modes occurs:

• The search fires a network request that returns HTTP 400 (Bad Request) from Spotify's API, but
  the UI shows a blank results page with no error state.
• On some browsers, the search request is dropped entirely and the results page simply renders
  as empty — indistinguishable from a legitimate 'no results' response.
  In both cases the user receives no feedback explaining why results are absent, making the failure
  invisible and confusing

To Reproduce
Steps to reproduce the behavior:

1. Navigate to open.spotify.com and log in to any free or Premium account.
2. Click the Search icon in the left sidebar.
3. In the search bar, paste a string of 300+ characters (e.g. repeat 'a' 300 times
4. Observe the search bar behaviour and any resulting UI/network activity.
5. Press Enter to confirm the search

Expected behavior

• The search bar should enforce a maximum character limit (e.g. 100–150 characters), visually
  indicating the cap with a counter or by refusing further input beyond the limit.

• If an oversized query somehow reaches the API and is rejected, the UI should surface a clear,
  human-readable error message such as: "Search query is too long. Please shorten it and try
  again."

• The application should never show a blank results page without distinguishing between 'no
  matching results' and 'query was invalid/rejected'.

• No character limit is enforced — the search bar accepts 300, 500, 1000+ characters without
  restriction.

• Submitting an overlong query either produces a blank results page (HTTP 400 returned silently)
  or no network request at all.

• No toast notification, inline error, or any UI indicator is shown to the user.

• DevTools Network tab reveals the 400 response, confirming the API is rejecting the query — but
  the frontend ignores the error state entirely.

Screenshots







Logs

Observed in DevTools → Network tab when submitting a 300-character query:
GET https://api-partner.spotify.com/pathfinder/v1/query?...searchTerm=aaaa[...300chars]
Response: 400 Bad Request
{"error": {"status": 400, "message": "Bad Request"}}
The frontend catches this response but renders no error state — the results container is populated as if
a legitimate empty search had been returned.

Two distinct gaps appear to be present:

• Missing frontend input validation — no maxlength attribute or character counter on the search
  element.
• Missing error-state handling in the search results component — the component does not
  differentiate between an empty-results response (200 OK, results: []) and an error response
  (400/5xx), so both render identically as a blank page.

Desktop (please complete the following information):

• OS:Windows 11,macOS,Linux
• Browser EDGE
• Version 146

Smartphone (please complete the following information):

• Device:iPhone17,Android16,Nokia,Xiaomi
• OS: iOS26,netHunter,HyperOS,WebOS25
• Browser: Safari,Firefox,Chrome
• Version 146, 148,26.3

Additional context

Impact Assessment
Who is affected?

• Any user who pastes a large block of text into the search bar — a common pattern when
  searching for lyrics, long song titles, or copied playlist names.
• Keyboard macro / accessibility tool users who may inadvertently produce long strings.
• Automated clients or bots querying the web player endpoint.
  UX impact
• High confusion: blank results with no error message mimics 'no results found', causing users to
  question their query rather than understanding a system error occurred.
• Trust erosion: silent failures make the search feel broken or unreliable.
  Technical impact
• Unnecessary API calls: each oversized query fires a network request that will always fail, wasting
  bandwidth and incrementing API error counters.
• Potential API rate-limit abuse if malicious actors exploit this to flood the endpoint.

Severity & Priority Rationale
Severity: S2
(High)
Core search functionality silently fails for a realistic user input pattern (pasting
text). No data loss or security breach, but a key feature is broken with no
recovery path visible to the user. Rated S2 rather than S1 because it only affects
oversized inputs — normal search queries are unaffected.
Priority: P2
(Should Fix)
Fix is straightforward: add maxlength on the input element AND add an error-
state branch in the results component. Low engineering effort, high UX payoff.
Not P1 because the failure path requires deliberately unusual input; typical daily
use is unaffected.

Suggested Fix
Frontend — search input element:
<input type="text" id="search-input" maxlength="150" ... />
Frontend — search results component (pseudo-code):
if (response.status === 400) {
showError('Your search is too long. Try a shorter term.');
} else if (results.length === 0) {
showEmptyState('No results found for "' + query + '"');
}
API — optionally enforce server-side as defence-in-depth (400 already returned — ensure consistent
error JSON schema).
Additional Notes

• Tested on Chrome 123, Firefox 124, Edge 122 — all reproduce the issue identically.
• Spotify's native desktop app (version 1.2.45) does NOT reproduce this bug — the desktop client
  enforces a visible character cap, suggesting this is a web-specific regression or omission.
• This report follows the GitHub Bug Report template structure (Title, Summary, Steps to
  Reproduce, Expected vs. Actual, Environment, Impact).

This bug was found during a focused exploratory testing session on Spotify Web Player's search feature.
The test heuristic used was the 'boundary value' approach — testing inputs at the extremes of what a
user might reasonably (or accidentally) enter.
I chose to report this specific bug for three reasons:

• Realism: Pasting copied text into a search bar is a genuine user behaviour, not an artificial
  adversarial input. This isn't a crafted exploit — it's a day-one QA case.
  Bug Report · Spotify Web Player · March 2026 | Page 3 of 4
• Signal clarity: The bug has a clean root cause (missing validation + missing error handling) with
  an unambiguous reproduction path and observable network evidence. This makes it high-
  quality signal, not noise.
• Fix value vs. fix cost: The frontend changes are small (one HTML attribute, one conditional
  render branch), but the UX improvement is meaningful — turning a confusing silent failure into
  clear, actionable feedback for the user.