I may be mistaken, but I get the impression that the question was focused on server side authentication (making sure the user actualy has access to the requested categories) rather than sanitization, which is always advisable. For this, I think a lot would depend on your actual system. Are you working within a commercial system, or something you are authoring yourself? What architectures does the system use: mvc, ddd, linear includes? It is possible that you have the components required already present.
Typically, in any system that makes use of a database as a storage medium, there are relational fields you can use to associate tables of data. So a simple SQL statement, with a few joins, could tell you right away if a particular user id has access to any given category id. This can be made easier with a good ORM or API, depending on your architecture.
Regardless, the client side script could still be tweaked to send a known combination of user id and category id that works. The way most people handle this is with an anti-forgery token. The way it works is when a page is requested for display (HTTP_GET) a one-time code is generated and associated with some client info (browser type and version, IP address, a generation timestamp, session id, etc). This is kept server side and is valid only for a short period. The submitted form must have this value present in order to validate the response. While the user might be able to guess a valid user id - category id combination, the chances of guessing this anti-forgery code is extremely unlikely. It is possible to output your page so that your JS also knows this value. By the time a user re-writes a pages JS, the code would be invalid (unless it was an automated process).
There is no sure-fire way to protect yourself, but these are some of the things we all face and should give you a starting point for coming up with your own solution.