I think we should separate the concept of clean URLs from that of a progressive numeric IDs. The security risk is related to enumeration of numeric IDs tied to internal DB's primary keys.
But :id can be anything. A progressive number, a UUID, a ksuid or a slug or anything else that uniquely identifies a resource.
Security wise having the progressive numeric ID in the URL or in the query string doesn't change anything.
I do realize that being inside body might make no difference as well?
It does, GET operations, though technically can have a body, are going to be identified only by the URL. Most HTTP servers completely ignore the request body in a GET request.
Yes. In other words, any HTTP request message is allowed to contain a message body, and thus must parse messages with that in mind. Server semantics for GET, however, are restricted such that a body, if any, has…
Now, I might be wrong, but both Request body and HTTP-only cookies, can be tracked by Network Tab in Chrome Dev Tools, in user's PC.
The only time it will be a threat, is whether it can be tracked via remote computer... HTTP-only cookies should not be able to be traced by JavaScript tricks -- not sure about Request Body, but every parts of URL (segments, query) definitely can be recorded..
HTTP only cookies can't be read by JavaScript yes, but if someone has physical access to your computer they might be the least of your worries :D
The content of the back and forth in the HTTP requests is going to be encrypted by the transport protocol if you use TLS but your "network tab" is obviously going to be able to see the content of the request/response, the goal is here to encrypt it when it's traveling through the wire. If the browser weren't able to decrypt the transmission you wouldn't even see this comment I'm writing.
Hope this helps!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I think we should separate the concept of clean URLs from that of a progressive numeric IDs. The security risk is related to enumeration of numeric IDs tied to internal DB's primary keys.
But
:idcan be anything. A progressive number, a UUID, a ksuid or a slug or anything else that uniquely identifies a resource.Security wise having the progressive numeric ID in the URL or in the query string doesn't change anything.
I do realize that being inside body might make no difference as well?
Unless it is inside HTTP-only cookies.
It does,
GEToperations, though technically can have a body, are going to be identified only by the URL. Most HTTP servers completely ignore the request body in a GET request.Roy Fielding's comment about including a body with a GET request.
what do you mean?
Now, I might be wrong, but both Request body and HTTP-only cookies, can be tracked by Network Tab in Chrome Dev Tools, in user's PC.
The only time it will be a threat, is whether it can be tracked via remote computer... HTTP-only cookies should not be able to be traced by JavaScript tricks -- not sure about Request Body, but every parts of URL (segments, query) definitely can be recorded..
HTTP only cookies can't be read by JavaScript yes, but if someone has physical access to your computer they might be the least of your worries :D
The content of the back and forth in the HTTP requests is going to be encrypted by the transport protocol if you use TLS but your "network tab" is obviously going to be able to see the content of the request/response, the goal is here to encrypt it when it's traveling through the wire. If the browser weren't able to decrypt the transmission you wouldn't even see this comment I'm writing.
Hope this helps!