Having the ID directly in the HTML is not inherently insecure per se.
However, I would worry about this: You seem to be using consecutive ids (Given that the example Id is a low number, I would guess it is an autoincrement or set by a trigger). This constitudes a user enumeration vulnerability.
Please use random ids or a reasonable length, doing so would mitigate the risk of a malicius user to guess Ids of users.
A malicious user can write a script that iterates over the ids and adds everybody as friend. Even if everbybody rejects (and I assure you, some won't, because there is people who accepts everybody), that script would annoy a lot of users, and add load to your servers.
This would be made worse the more functions the user can call with these ids (for example, this could reveal private or sensitive information about the user. Make sure to check who is requesting and whatever or not they have access to such information), and even worse if there is an SQL Injection vulnerability (the fact that you mention a query in the comments makes me worry about this, please use prepared statements, thank you).
There is also a risk of cross-site attacks. Your function addFriend
will have to ultimately translate to some request to the server, right? If there is chance to mimic that request (cross-site request forgery) or call the function (cross-site scripting), a malicious user could send a link to the victim that when open - while the victim has an open session on your site - would result in a third party added as friend.
There are plenty of things to do to mitigate cross-site attacks. Please refer to Owasp articles on Cross-Site Requst Forgery and Cross-Site Scripting.
You will find that one thing you can do is generate codes that mean "Add X as Friend" that are single use and tied to the session of the user. This would mean that no script or request forgery will be able to add a friend for which the code has not been generated. And the same approach can be done for any other function or request that needs to be secured.
Other things you may consider: You may also "add a cooldown" to the operation, making sure that a function that calls them in rapid succesion does not work. In fact, executing one could invalidate and regenerate all other codes, making any script that reads them and use them way harded to implement (plus you would know who keeps doing it and yield a temporary ban).
Addendum: Use Captcha in conspicuous activity.
Note: Do not store these in the permanent database. Out of personal experience, that becomes a mess very quickly. Also do not tie them to the user, but to the session. In fact, using session variables (even if backed by a database) is a good approach.
However, instead of storing all the valid codes (and saving storage on the server), you can generate and store a criptographic key and use it to cipher codes that represent the operation. If you do this, invalidating the codes imply replacing the key with a new one.
See also: The Moonpig Bug: How 3,000,000 Customers' Details Were Exposed where Tom Scott explains a user enumeration vulnerability.