TL;DR: Use sessions over SSL
You are correct, this is a bad thing. The general rule of security in an application, never trust the user, applies here. The issue, is a lazy web developer will believe that a cookie doesn't count as user input.
This could not be further from the case. It is exceptionally easy to make modifications to any data sent to the server from the client, whether it be direct user input or a cookie.
There are plenty of use cases for cookies, and they play a key role in web security, but it this case, it sounds like they are about as secure as a hidden form element.
So how do you fix this? Sessions. A session also stores data as a cookie, but unlike your cookies, is just a long string. This serves as a secure (with a caveat) method for the server to identify a user. With each HTTP request, the session id is included. Once the server has associated a session with a client, relevant session data is stored on the server. The server knows what session to access based on the id sent by the client.
A session id is better for a few reasons, the server controls the data associated with the session, not the client. For example, you might store your cart total as a session variable. If the client had direct access to this, they could modify the amount they pay after you have submitted the purchase order, but before their card is charged.
You could safely store the privilege level of a user as a session variable, where it would be unsafe to do so as a regular cookie as well.
Now to the caveats. A session id is still not 100% secure. If I were to log onto your site over a public network, my authentication would be successful, and you would provide me a session id. Now, anyone who knows this id can use it to send HTTP requests as me. This is session hijacking. There also exist some timing attacks and such that attempt to reduce the entropy that exists in the session id.
You should only allow a user to login or communicate securely with your server over an SSL/TLS connection. This will greatly reduce the chances of a MITM attack or session hijacking. If you can also reset the session id and require the user to have entered their credentials within a certain timeframe. For example, hopefully your bank forces you to re login after a certain amount of time.
Here are some code examples in php for using sessions
session_start() // You must include this at the top of every page basically
// I know, its odd, just go with it
$_SESSION['username'] = $user // How you could save the username to a session
session_unset() // Clear out the session (logout the user). If you really care
// about security you will overwrite each session var first