RTSP exposure check: is your camera's stream reachable without authentication?
How does this check work, and what does the result tell you?
AdminKit checks whether the public IP you are connecting from has an RTSP camera or video server reachable from the internet, sending only an OPTIONS and a DESCRIBE request on port 554 by default, so it reads back whether the stream's description is viewable without authentication, never the video feed itself or any credential.
Part of the Machine protocols cluster — more tools, guides and terms on machine protocols.
AI explanation Run a check below, then sign in to ask AI to explain the result in plain language.
This checks only the public IP address you are connecting from right now — never a host you type in, and never someone else's camera or server.
Next step
Also check other commonly exposed ports on the same IP, or see MQTT exposure for a related machine-protocol check.
Keep this result
Copy a link to this check so you can share it or run it again later. Want a heads-up if something changes? That's early access, not a live feature yet — tell us and we'll set it up by hand.
How it works and limits
RTSP (RFC 2326, updated by RFC 7826) is the control protocol most IP cameras, NVRs and video doorbells use to negotiate a live video stream, almost always on port 554. The protocol defines no mandatory authentication or encryption of its own, so whether a stream requires credentials is entirely up to the device’s own configuration — and a large share of consumer and budget cameras ship with it disabled.
What it checks
- Whether the public IP you are connecting from answers on RTSP’s default port 554 (or a port you specify) at all.
OPTIONS: which RTSP methods the server advertises support for.DESCRIBE: whether the server hands back the stream’s SDP description — codec, resolution and stream-URL metadata — to a request carrying no credentials, or instead requires authentication (401/403).
What it won’t do
- It never sends
SETUPorPLAY— the RTSP methods that actually open a media stream — so no video is ever fetched, viewed or recorded. - It never sends a username or password; it only observes whether the server demanded one.
- It never probes a host you did not request the check against — see “Why does it only check my own IP?” below.
Limits
- A “stream description exposed” result means the camera’s metadata was readable without credentials, which is itself a meaningful exposure (anyone who finds the stream URL can view the feed) — it is not a statement about separate, implementation-specific RTSP vulnerabilities a given device might also carry.
- No query is logged; see /legal/privacy/.
Check manually today
A minimal, unauthenticated OPTIONS request looks like:
printf 'OPTIONS rtsp://HOST:554/ RTSP/1.0\r\nCSeq: 1\r\n\r\n' | nc -w 3 HOST 554A RTSP/1.0 200 OK reply with a Public: header listing DESCRIBE means the same DESCRIBE probe this tool runs
would likely succeed too — only test a camera or server you own or are authorized to test.
If this turns up an exposed stream, enable the camera’s built-in RTSP authentication if it offers one, and remove any port-forward exposing the RTSP port directly to the internet — see is port 554 (RTSP) exposed? for the full walkthrough and Telnet and RTSP camera exposure for the closely related Telnet admin-shell issue that shows up on the same hardware. Reference: RTSP. See also open ports on my IP for a broader scan of commonly exposed device ports on the same IP.
Frequently asked questions
Is this check live?
Yes — it sends a real `OPTIONS` and `DESCRIBE` request via AdminKit's Check API (POST /v1/check/rtsp), the same endpoint anyone can call anonymously, rate-limited per visitor. Like AdminKit's open ports check, it only ever probes the public IP address the request comes from or an asset you've verified ownership of — there is no field to type in someone else's camera, so unlike MQTT and Modbus exposure checks, this one works as a live, self-check tool for every visitor today.
Will it watch, record or control my camera?
No. The probe stops after two requests — `OPTIONS` to list the methods a server supports, and `DESCRIBE` to read back the stream's session description — both read-only metadata requests defined in RFC 2326 (RTSP 1.0) §10.1–10.4 and RFC 7826 (RTSP 2.0) §13.1–13.2. It never sends `SETUP` or `PLAY`, the methods that would actually open a media stream, so no video is ever fetched, viewed or recorded, and no username or password is ever sent.
What does 'stream description exposed' mean?
`DESCRIBE` returning HTTP-style status 200 means the server handed back an SDP (Session Description Protocol) body — codec, resolution and stream-URL metadata about the camera's feed — to an anonymous request with no credentials. RFC 2326 §10.4 and RFC 7826 §13.2 define `DESCRIBE` as returning exactly this description; a server that requires authentication instead replies 401 or 403, which this tool reports as a separate, lower-risk state.
Why does it only check my own IP, not a camera I don't own?
Like every active AdminKit check, an RTSP probe only runs against your own IP or an asset you've verified ownership of — an unverified host gets no active connection at all. That is also why the check always reads your current public IP automatically rather than offering a field to type a host into: there would be nothing honest to show for any address but your own.
What if my camera's RTSP port isn't 554?
Enter the external port your router actually forwards before running the check — many home setups forward a different external port (e.g. 8554) to the camera's internal 554 to avoid clashing with other devices. The check always probes port 554 by default, matching the port IANA registers for the `rtsp` service, unless you specify another one.