Hacker News Reader

Comment by raquo | Hacker News Reader

I never had any uncertainty regarding where I can use a given entity id in a well designed API. Fix the naming and organization of your API if that's a problem for your users.

Conversely, I often need to log or store API-provided entity ids on my side, and having to parse it out of a URL or store irrelevant URL bytes in my own database would be really annoying.

You're not going to avoid the need to compile entity URLs on the client side either, unless you only make requests to entities returned by the API, which would be a weird constraint to design client code around.

I really don't see the point to any of this.

View on HN

I would never feel comfortable `fetch`-ing the URI provided by the API without validation. That sounds like a security issue waiting to happen.

The browser already does it with the anchor tag and the user decides to navigate or not, the difference in an API is that it's a machine driving. What's the security issue you're talking about?

SSRF is the most obvious (potential) issue.

Does an API returning only relative URLs address your concern?

The validation would be intrinsic in the client side concatenation of the server address with the relative URI.

If you save the relative URL in your database and then the API changes its URL schema, you will need to migrate everything you stored to the new schema.

If all you stored was the ID, all you would need to change is the logic in your API client which accepts the ID and constructs the URL for it.

a change that necessitate a URL schema change would be just as far reaching had the system been designed with using IDs.

For example, if the entity ID changes from being an integer, to being a GUID, you'd still have to write code to update your schema (presumably, from an int column to a GUID/string column).

(Not the GP) Yes, when done right, but it's iffy.

For example, the article includes URLs like "/people/123". The security of having a leading slash in these depends on API base URL.

"https://api.hotstartup.com/v1" – safe

"https://api.hotstartup.com" – unsafe with ".evil.com/people/123"

I wouldn't really call this particular scenario a security issue, but allowing such things is a bad habit that will eventually bite. It's like not HTML-encoding values like usernames that you "know" are safe (but you know are not HTML-encoded).

Yes, this is why developers should use URI-building libraries instead of direct string manipulation to modify URIs.

If I visit an HTML page with a link to “.evil.com/people/123” and click on it, the user agent won’t append “.evil.com” to the hostname. You’d instead get something like “https://api.hotstartup.com/.evil.com/people/123” which would be safe (if not broken).

A lot of environments have whitelisted outgoing connections.

And a lot of them don't.

You don't have to parse entity IDs our of URLs — the URL already is an entity ID, and from the client's perspecitive, it doesn't have any sub-parts that can be parsed out, except those defined in the URI spec (scheme, authority)

That only works if fetching the /people/123 URL is the only thing you will ever do. If you need the real 123 entity id in any other context, e.g. to display it to the user, or to make a user-accessible website link to that entity (e.g. "view this transaction in stripe dashboard"), you'll need parsing.

I also mentioned that I don't want to store redundant garbage in my logs and database, especially if I want to index the column containing that entity id.

Reply on news.ycombinator.com