Proper session-handling and function level access control is a very important point in web security (Check out OWASP Session Management and Function Level Access Control).
Always make sure that session tokens are really only valid for actions that a certain user is allowed to perform. And only for that certain user.
That's a very big issue, and 99% of all websites I've tested so far were vulnerable to attacks evolving around that. E.g. when tokens could be used to perform actions, that the currently logged in user shouldn't be able to do. Like: replacing an ID in a request with the ID of another user (or record). You would be surprised how often that extremely simple method works to get PII of other users!
- All urls are only accessible to users with the certain privilege.
- Users shouldn't be able to simply add fields to a request. Good example: I saw multiple websites/apps already, where it was possible to hijack other user accounts by simply adding an 'email' field in the form where every user could change his own profile information.
- Make sure that your way of granting roles to users/admins is safe, and that users cannot grant themselfes additional privileges/roles.
- The password-reset forms are also often a good entry point for attackers, and be it only to spam other users.
Sessions must be destroyed on logout/password change, and not be reused at any time.
Apart from that you should also worry about information disclosure (when an attacker enforces errors, for example with invalid HTTP-requests or -methods, like OPTION instead of OPTIONS).
Never disclose any sensitive information - e.g. make sure that session tokens are never transmitted via GET-requests.
Also make sure that your server only allows certain HTTP-methods (e.g. don't allow "TRACE").
Input validation: secure all file-upload forms, they are very vulnerable. E.g. payload in the filename. I've also often seen that the maximum file-size was only validated on the client side.
Use captchas where needed, and make sure they can't be circumvented due to a bad implementation.
Last but not least you should also worry about open redirects.
I could go on with this list for a while, but I suggest you just follow up by reading some checklists like this one: https://kennel209.gitbooks.io/owasp-testing-guide-v4/content/en/web_application_security_testing/testing_checklist.html