A useful WebSocket test connects one authorized user action to the handshake, the client message and the server’s observable decision. Start with a controlled capture; only replay or modify messages when their effects are understood and permitted. An unchanged replay can still create a duplicate order, payment or notification.
This guide explains a repeatable review method using Burp Proxy and Repeater. It does not report a completed assessment or promise a vulnerability. Product behavior was checked against the linked documentation on October 16, 2026; confirm the controls available in your installed version.
Define permission and reversible test data
Agree on the application, accounts, endpoints, environments and permitted actions before connecting. Establish whether reconnects, duplicate submissions, cross-origin browser tests and rate or size checks are allowed. A general penetration-test authorization does not automatically settle every operational limit.
Prefer test accounts and resources you control. Identify state-changing messages and a cleanup procedure. If a message can charge, delete, approve or notify, stop at capture until the owner authorizes a safe replay. Do not use real customer identifiers or copy session secrets into a report.
Record the handshake and distinguish its fields
Capture the destination, transport, requested subprotocol, Origin and the presence of authentication material. Redact cookies and tokens in shared evidence. Identify which credential the application actually validates; a header’s presence alone does not establish its security role.
In the classic HTTP/1.1 upgrade described by RFC 6455, the handshake establishes a WebSocket connection. The Sec-WebSocket-Key value is not an authentication credential, and client masking is not encryption. WSS protects transport; it does not prove that the server checks access to each object.
Match a browser action to the right connection
In Proxy WebSockets history, compare the destination and connection identifier with the timing and direction of messages. Perform one low-impact UI action and record the messages surrounding it. Busy chat, analytics and application channels may coexist.
A matching timestamp is a lead, not sufficient proof. Check the message’s operation and object identifiers and confirm the resulting application state with your test account. Preserve enough surrounding traffic to distinguish the action from background synchronization.
Use history as a record with limits
Keep an unfiltered capture for the permitted test and note the account role, connection, timestamp and starting state. Capture the corresponding response or event and the browser result. History records what Burp observed; missing messages, another transport or an unproxied connection can leave gaps.
Separate Proxy traffic from messages generated manually in Repeater. Repeater maintains its own WebSocket message history, including manually sent messages. Do not assume a manual send will appear as ordinary browser traffic in Proxy history. Explain the source of each excerpt in the report.
Filter for review without discarding evidence
Use the history controls supported by your Burp version to narrow the connection or direction. Retain the original capture and review excluded traffic before concluding that no response occurred. A keyword filter can hide errors, acknowledgments or the very event you need.
Protocol Ping and Pong control frames differ from application heartbeat messages carried as data. Do not remove every payload containing “ping” or “pong”: those strings may occur in valid application content. Document the filter when presenting a reduced view.
Send a permitted message to Repeater
PortSwigger’s WebSocket Repeater instructions describe sending a message to Repeater, selecting its destination and reviewing the response in Repeater’s history. Confirm the correct connection and direction before sending. An unchanged baseline is appropriate only when its side effects are safe and authorized.
Client-directed messages can be sent only through a connection that is still open via Burp Proxy. A browser reaction to an injected server-to-client message demonstrates that client-side path; it does not show that an attacker can make the real server produce that message or bypass server authorization.
Reconnect with explicit session and state checks
Repeater’s connection controls support attaching to an open connection, cloning one or creating a new connection and editing its negotiation request. Consult the current documentation rather than relying on an assumed button sequence. Keep the original exchange as a comparison.
A new connection may require valid credentials, a subscription, a join operation or a fresh sequence value. Reconnecting is not an automatic restoration of application state. Record the identity and setup messages actually used, and distinguish an expired session from an authorization rejection.
Change one variable and verify the outcome
For each permitted mutation, state the expected secure behavior before sending. Keep connection identity and starting state stable where possible, change one relevant value and record the observed decision. Repeat only when the operation is reversible and the repeated request will not create additional harm.
Common mistakes include selecting the wrong socket, replaying an order-dependent message in isolation, retaining a privileged connection while claiming to test a lower role, hiding the response with a filter and interpreting silence as success. A response code or echoed value alone does not establish unauthorized access.
Separate authorization tests from browser-origin tests
For an object or tenant access check, use two resources and accounts under your control. Establish a separate, verified lower-privilege connection and attempt only the agreed operation against the other test resource. Confirm whether the server withheld the data or state change; changing an account identifier inside a privileged channel is not an equivalent test.
For cross-site WebSocket hijacking, review how the handshake authenticates and whether a controlled cross-origin browser context can establish and use the connection. Editing Origin in Repeater does not reproduce browser cookie rules or demonstrate a browser-based attack. Record browser behavior and the limited test-account impact.
Recommend controls that match the confirmed weakness
Use the OWASP WebSocket security guidance to review secure transport, allowed origins, authentication, session lifetime, message-level authorization, input validation and resource limits. Authenticate a connection and check each sensitive action against its object and tenant; client-side filtering cannot enforce that boundary.
Specify the observed gap, the required decision and a retest case. Consider logout and expiry for long-lived connections, controlled message sizes and rates, and logs that identify decisions without retaining credentials or unnecessary payloads. Do not introduce a universal numeric limit without workload and availability requirements.
Build a concise evidence pack
Include the authorized scenario, redacted handshake, verified account roles, required setup messages, the single changed field, expected behavior and actual response or state. Show an allowed control case and the denied case where relevant. Preserve private evidence in the agreed location and share the minimum needed to reproduce the issue.
Label uncertainty directly: an unexplained disconnect is not proof of a vulnerability, and a successful manual message is not automatically a browser exploit. This workflow has no reliability score or estimated completion time; the evidence and reproducible application outcome determine the finding.
Common questions
Does no visible response mean the server rejected the request? No. Check the correct connection, Repeater history, filtered traffic and application state. Some operations are asynchronous or produce no direct reply.
Can a captured session always be replayed? No. Credentials can expire, connections can close and application state can change. A replay may also duplicate an action. Review both authorization and side effects before sending.
Next step: one controlled scenario
Choose one authorized, reversible action and follow it from handshake to observable result. Preserve the original capture, record identity and direction, and add one carefully scoped test. Expand coverage only when the setup and the application’s decision are clear.