Q:

UUID on database level used as a security measure instead of a true rights control? 

Can UUID on database level be used as a security measure instead of a true rights control? 
Consider a web application where all servlets implements "normal" access control by having a session id connected to the user calling it (through the web client).  All users are therefore authenticated. 
The next level of security needed is if a authenticated user actually "owns" the data being changed.  In a web application this could for example be editing some text in a form.  The client makes sure a user, by accident, doesn’t do something wrong (JavaScript).  The issue is of course is that any number of network tools could easily repeat the call made by the browser and, by only changing the ID, edit a different row in the database table behind the servlet that the user does not "own". 
My question is if it would be sufficient to use UUID's as keys in the database table and thereby making it practically impossible to guess a valid ID (https://en.wikipedia.org/wiki/Universally_unique_identifier#Random_UUID_probability_of_duplicates)?  As far as I know similar approaches is used in Google Photos (http://www.theverge.com/2015/6/23/8830977/google-photos-security-public-url-privacy-protected) but I'm not sure it is 100% comparable. 
Another option is off cause to have every servlet verify that the user is only performing an action on its own data, but in a big application with 200+ servlets and 50-100 tables this could be a very cumbersome task where mistakes could easily happen.  In my mind this weakens the security far more, but I'm not sure if that is true. 
I'm leaning towards the UUID solution, but I'm also curious if there are other obvious approaches to this problem that I ought to consider. 
Update:
I should probably have clarified that my plan would be to use UUIDv4 which is supposed to be random.  I know that entropy comes in to play here in regards to how random the UUID's actually are, but as far as I have read then Java (which is the selected platform/language) uses SecureRandom which is supposed to be "cryptographically strong" (link). 
And in that case wiki states (link):
In other words, only after generating 1 billion UUIDs every second for the next 100 years, the probability of creating just one duplicate would be about 50%. 

A:

Another option is off cause to have every servlet verify that the user
  is only performing an action on its own data, but in a big application
  with 200+ servlets and 50-100 tables this could be a very cumbersome
  task where mistakes could easily happen.  In my mind this weakens the
  security far more, but I'm not sure if that is true. 

With a large legacy application adding in security later is always a complex task.  And you're right - the more complicated an application, the harder it is to verify security.  Complexity is the main enemy of security. 
However, this is the best way to go rather than by trying to obscure insecure direct object reference problems. 
If you are using these UUIDs in the query string then this information within URLs may be logged in various locations, including the user's browser, the web server, and any forward or reverse proxy servers between the two endpoints.  URLs may also be displayed on-screen, bookmarked or emailed around by users.  They may be disclosed to third parties via the Referer header when any off-site links are followed.  Placing direct object references into the URL increases the risk that they will be captured by an attacker.  An existing user of the application that then has their access revoked to certain bits of data - they will still be able to access this data by using a previously bookmarked URL (or by using their browser history).  Even where the ID is passed outside of the URL mechanism, a local attacker that knows (or has figured out) how your system works could have purposely saved IDs just for the occasion. 
As said by other answers, GUIDs/UUIDs are not meant to be unguessable, they are just meant to be unique.  Granted, the Java implementation does actually generate cryptographically secure random numbers.  However, what if this implementation changes in future releases, or what if your system is ported elsewhere where this functionality is different?  If you're going to do this, you might as well generate your own cryptographically secure random numbers using your own implementation to use as identifiers.  If you have 128bits of entropy in your identifiers, it is completely infeasible for anyone ever to guess them (even if they had all of the world's computing power). 
However, for the above reasons I recommend you implement access checks instead.