In the last part of this series, I ran through a few tools you can use to check how secure your script is. I gave a quick rundown on how to check things out with SQLmap. I asked you to take a look at our login system with any of the tools I mentioned. Actually, the login system I put together in the second part of this series might look pretty solid and secure to folks who aren’t deep into programming. But the truth is, it skips out on a bunch of important practices and features that would make it way more secure. For example... 1- Using SELECT * in our SQL queries is like opening our whole fridge when we only need a snack. It drags out all the columns from the table, which can slow down our system and waste resources, especially when dealing with big tables. If a hacker manages to inject their own SQL, they could see way more data than they should. 2- Not auto-updating our password hashes is like using an old lock on our front door. If we're sticking with outdated hashing methods, it’s a breeze for hackers to crack those passwords if they snag the hashed data. Regularly refreshing your hashing algorithms keeps things tighter and safer. 3- Keeping our database connection open 24/7 is like leaving your front door wide open—it's a big waste and invites trouble. It hogs resources and gives hackers more chances to find weak spots and mess things up. Only open those connections when you really need them, and shut them down as soon as you're done. 4- Letting folks try endless passwords is like giving them a free pass to guess the code to your safe. This opens up the door for brute force attacks where hackers try every combination until they hit the jackpot. Setting limits on login attempts, like locking accounts after several failed tries, helps fend off these attacks. So, after taking a close look at our code, I pinpointed several security issues and rated each script based on how vulnerable it might be and how well it follows best practices. In **index.php**, I noticed CSRF protection and CAPTCHA validation are on point. The CSRF token is generated and checked right, and Google reCAPTCHA is doing its job to block bots. Plus, we’re sanitizing user inputs with `filter_input()` and handling password verification securely with `password_verify()`. However, we could beef up error handling to make sure we’re not showing raw error messages to users. Overall, this script gets an 80% for its solid core security features, though there's room to tighten up error handling. For **otp_verification.php**, the session management is solid, keeping things locked down to authorized users only. OTP input is sanitized, and we’re checking both the OTP code and its expiry. But we could step up session security to avoid problems like session fixation or hijacking. Also, error handling could be better to keep sensitive info under wraps. This one scores 85%, thanks to strong OTP verification and session management, but there's still room for improvement in session security and error handling. In **dashboard.php**, session management is doing its job, and output is sanitized with `htmlspecialchars()` to keep XSS attacks at bay. Still, we need to make sure session security is rock solid to fend off hijacking. The script’s handling of sessions and output is good, but we can always do more to beef up session security. This file gets a 90% for its effective session and output sanitization, with some extra attention needed on session security. **config.php** is where we’ve got a big security risk with hardcoded database credentials. Credentials should be managed through environment variables or a secure system, not hardcoded. We need to make sure database connection details are kept secure. This script scores 70% due to the risks of hardcoded credentials and the need for better secure storage practices. In **functions.php**, password hashing is handled well with `password_hash()` and `password_verify()`. We’re using prepared statements to dodge SQL injection, and PHPMailer is set up for sending OTP emails. However, we should secure SMTP credentials and improve database error handling. While password and SQL query handling is strong, we can further improve email security and database practices. This script scores 85%. Finally, **register.php** has solid CSRF protection and CAPTCHA validation. Input fields are sanitized and validated, which is great for the registration process. But we could improve CAPTCHA setup and error handling to better guard against automated attacks and avoid exposing raw errors. This script scores 80%, reflecting good security features with room for improvement in CAPTCHA and error handling. Overall, our security score is 80%. The code shows strong core security features like CSRF protection, CAPTCHA, password hashing, and prepared statements. To hit a perfect score, focus on managing sensitive info securely, enhancing error handling, and improving session and email security. Regular security audits and vulnerability checks will also help us keep things tight. In this part, I won’t dive into how to fix these security vulnerabilities with PHP for a bunch of reasons. But don’t worry—I’ve already tackled these issues. You can check out the updated scripts on my GitHub account. [login_registration_system on GitHub](https://github.com/majdi-php-sql/login_registration_system) I wouldn’t get too caught up on the changes I made just yet—we’ll cover those in detail in the next part. For now, focus on really understanding these security vulnerabilities. Read up on them and dive deep into grasping how they work. Good Luck,