A municipal chat feature uses WebSockets for permit-status actions. What authorization concern should the tester apply?
Select an answer to reveal the explanation.
Short Explanation
A side door still needs a lock. WebSockets are just another channel into the same business actions — if HTTP checks who may update a permit, the socket messages need the same checks. Skipping them because they are not REST is how IDOR-class bugs hide in plain sight.
Full Explanation
Municipal chat features that move permit-status actions onto WebSockets still require the same authentication and authorization guarantees as ordinary HTTP endpoints. Each message or action must bind to an authenticated principal and enforce object-level authorization; channel upgrade alone does not create a privileged free-fire zone for civic workflows.
Skipping WebSocket testing because only REST APIs can have IDOR-class flaws is wrong—authorization bugs follow the action model, not the transport brand. Treating any open WebSocket as proven remote code execution skips evidence and overstates impact. Recommending that operators disable TLS on WebSockets so production traffic is easier to inspect weakens civic confidentiality and is not legitimate remediation.
Exam caveat: WebSocket and HTTP APIs may share session cookies or tokens; testers must verify whether authentication and authorization are re-checked per action or only at handshake time.
Operational check: authenticate as a limited civic user, attempt WebSocket actions against another resident's permit identifiers, and confirm the server rejects unauthorized operations with clear evidence. Document missing checks as authorization findings parallel to REST IDOR classes for the municipal chat feature.