Skip to content

API security

WebSocket origin and session review

Verify browser WebSocket handshakes reject untrusted origins and handle logout or expiration for a controlled account.

By BugSnaps · Updated

Add BugSnaps as a preferred source on Google(opens in a new tab)

Want more of our security guides? Select BugSnaps and confirm your choice on Google.

Direct answer

A WebSocket can outlive the HTTP request that created it. Check the browser origin, authentication and session termination behavior according to the application's intended design.

Map the live connection

Identify the WebSocket endpoint, allowed web origins, authentication method and expected behavior after logout or expiry. Use a dedicated account and a test environment. Record whether the browser automatically attaches a session cookie to the handshake.

Reference: OWASP WebSocket Security Cheat Sheet.

Compare controlled origins

Connect from the approved application origin, then from an assessor-controlled unapproved origin with the same test browser session. Inspect whether the server accepts the handshake and delivers protected test messages. Avoid exposing cookies or tokens in evidence.

  • Use a harmless channel and synthetic records.
  • Record browser, origin and expected result.
  • Do not assume non-browser clients have trustworthy Origin headers.

Test session termination

Keep a test connection open, log out through the normal flow and check whether subsequent messages are accepted or the connection closes under the documented policy. Test expiration separately where practical, including any permitted refresh process.

Retest without breaking clients

After a fix, verify the approved application reconnects and the unapproved origin cannot establish the protected session. Confirm the logged-out connection no longer receives protected events, and review server-side enforcement rather than relying only on a browser restriction.

Assessment limits

Origin validation addresses browser-origin risks but does not authenticate arbitrary non-browser clients or authorize each message. A single session does not prove all live connections are invalidated.

Frequently asked questions

Does a successful WebSocket handshake authorize every message?

No. The server must enforce the relevant action and object permissions throughout the connection.

Is a browser Origin header a complete client identity?

No. It is useful for browser-origin checks, while other clients can supply their own headers and need authentication.

Primary sources and further reading

These guides combine published security guidance with practical assessment planning. Adapt checks to the owner's policy, environment, and authorized scope.

This guide was prepared with AI assistance using the linked sources and illustrative examples. Check current vendor guidance and your environment before making changes.

Apply the guide to your own assessment.

Start with an authorized target, known test data, and a clear scope. Use the report's evidence and coverage limits to decide which checks need further review.

Open MyPentest