Web application security goes really really deep. First, you need to use sessions, or an equivalent implementation of sessions.
The user logs in, and you need a session ID and their username to be stored in a cookie and in the database. In the database you also need to store some information about them, such as their user agent, so that you can tell if their session becomes hijacked. Some people store the IP address. This won't work if the user is using your application from a mobile device, as their IP address may refresh frequently.
Every time a user loads an administrative page, verify that they have a session and user cookie that are valid and have permission to use that page. Then verify the request came from the same computer that it started from using the information you stored about that user.
For every form or link you put in the administration page which can lead to an administrative action, add a hidden field or value with a unique identifier. One identifier per item on the page that could lead to administrative action. When you generate these identifiers, store them in the database along with what action they are identifying. This is called a nonce, it will be submitted with each admin request (such as updating records or deleting users or transferring funds from your bank account). When the request is serviced, the server should check that the nonce matches what was stored in the database, and then get rid of it. If it doesn't match, chances are the request was made via a cross-site request forgery attack.
These are just some of the things to keep in mind when interacting with authenticated users, and of course there is a host of other things to watch out for such as XSS.
Security is very hard, and while your web application may not warrant bullet-proof security strategies, you owe it to your users to protect their passwords and personal information. See OWASP for (much) more information.