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.

(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).

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).

And a lot of them don't.