I Checked My Website Like a Hacker Would. Here Are 7 Security Mistakes Developers Should Never Ignore
You don't need to be an attacker to think like one. Sometimes, looking at your application from a different perspective reveals security problems that ordinary testing misses.
As developers, we spend a lot of time making applications work.
We build login systems, connect APIs, create dashboards, manage databases, and make sure users can complete the tasks they came to perform.
But there is another question every developer should ask:
What happens when someone uses my application in a way I never intended?
What happens when a user changes an ID in a URL, submits unexpected input, sends a request directly to the backend, or tries to access a feature they should not be allowed to use?
These are the kinds of questions that separate ordinary functionality testing from security testing.
You do not need to break into somebody else's system to learn how attackers think. You can start with an application you own, a local development environment, or a deliberately vulnerable lab.
Here are seven security weaknesses I believe developers should learn to recognize.
1. Broken Access Control: Can One User Access Another User's Data?
Imagine you are developing a platform where customers can view their orders.
A user visits:
"/orders/1001"
The application displays the correct order.
But what happens if that user changes the URL to:
"/orders/1002"
If the application displays another customer's private information without checking authorization, the application has a serious security weakness.
This type of issue can fall under Broken Access Control and, in API environments, Broken Object Level Authorization (BOLA).
The problem is not that the user changed a number. The problem is that the server failed to verify whether the user was allowed to access the requested resource.
What developers should do:
- Enforce authorization on the server.
- Check resource ownership and permissions for every sensitive operation.
- Test access using different user accounts and roles.
- Never rely on hidden buttons or unpredictable IDs as security controls.
A resource ID is a reference to an object, not proof of permission to access it.
2. SQL Injection: What Happens When Input Becomes Part of a Database Query?
Applications frequently accept user input through search boxes, login forms, filters, and other interfaces.
The danger begins when an application treats untrusted input as part of a database command rather than as data.
This can create SQL injection vulnerabilities, potentially allowing an attacker to manipulate database queries.
For example, consider a PHP application that constructs SQL by joining user input directly into a query string.
That approach can become dangerous because the input may change the meaning of the query.
What developers should do:
Use parameterized queries or prepared statements, avoid constructing SQL commands through unsafe string concatenation, and apply appropriate database permissions.
Frameworks can help, but they do not eliminate every risk. Developers can still introduce injection vulnerabilities when they bypass safe query mechanisms or construct dynamic queries incorrectly.
If you want to learn this safely, practice in a deliberately vulnerable application such as OWASP Juice Shop or WebGoat.
3. Weak Authentication: Is a Password Enough?
A login page may appear secure because it requires a username and password.
But authentication security involves much more than the login form itself.
Questions worth asking include:
- Are passwords stored using an appropriate password-hashing algorithm?
- Is multi-factor authentication available for sensitive accounts?
- Are login attempts protected against automated abuse?
- Can password-reset processes be manipulated?
- Are session tokens handled securely?
An application can have a perfectly designed login page and still have weaknesses in its account recovery or session-management processes.
What developers should do:
Use established authentication libraries and framework features, hash passwords using appropriate password-hashing algorithms, protect account recovery, and consider rate limiting and multi-factor authentication.
Avoid designing your own cryptographic authentication mechanisms unless there is a compelling, well-reviewed reason to do so.
4. Exposed Secrets: Are Your API Keys Hiding in Plain Sight?
This is one of the easiest mistakes to overlook during development.
A developer creates an API key, adds it to a project, and pushes the code to a repository.
The application works, so the developer moves on.
But if a sensitive secret becomes accessible to unauthorized people, the consequences may include unauthorized API usage, data exposure, or access to connected services.
Secrets can leak through source code, logs, configuration files, build artifacts, or incorrectly configured repositories.
What developers should do:
- Keep secrets out of source control.
- Use environment variables or a dedicated secrets-management solution appropriate to the environment.
- Restrict credentials to the minimum permissions required.
- Rotate exposed credentials and investigate possible misuse.
- Remember that frontend code is visible to users, so secrets must never be placed in client-side bundles.
Adding a secret to a file named ".env" is not enough by itself. You must also ensure the file is excluded from version control and cannot be downloaded through a misconfigured web server.
5. Cross-Site Scripting (XSS): Can Your Application Execute Untrusted Content?
Suppose your application allows users to publish comments, submit profile descriptions, or post product reviews.
If the application handles untrusted content incorrectly, it may create a cross-site scripting vulnerability.
Get Samuel Oluwatosin Adesanya’s stories in your inbox
Join Medium for free to get updates from this writer.
Depending on the context, an attacker may be able to execute malicious scripts in another user's browser within the security context of the affected application.
This can undermine user trust and potentially expose sensitive information or enable unwanted actions.
What developers should do:
- Use context-aware output encoding.
- Prefer safe templating features that escape untrusted content.
- Avoid inserting untrusted strings into HTML using unsafe DOM operations.
- Sanitize user-generated HTML when the application genuinely needs to support it.
- Consider a Content Security Policy as an additional defensive layer.
Input validation is useful, but it is not a universal replacement for safe output handling.
The correct defence depends on where and how the data is used.
6. Security Misconfiguration: Is Your Development Setup Exposed to the Internet?
Developers often use test environments, debugging tools, temporary files, and sample accounts while building applications.
The problem arises when these conveniences remain in production.
Examples include:
- Debug mode exposing detailed error information.
- Default administrator credentials remaining active.
- Database management tools being publicly accessible.
- Unnecessary services or ports being exposed.
- Backups or configuration files being downloadable.
- Cloud storage permissions being broader than intended.
An application does not need an advanced vulnerability to become exposed. Sometimes, a configuration mistake is enough.
What developers should do:
Review production configuration before deployment, disable debugging features intended only for development, remove sample accounts and unnecessary services, restrict administrative interfaces, and verify that sensitive files are not publicly accessible.
Security configuration should be part of deployment, not something checked only after a problem occurs.
7. Outdated Dependencies: Is Your Application Carrying an Old Vulnerability?
Modern applications depend on external packages, libraries, frameworks, and services.
These dependencies save development time, but they also introduce security responsibilities.
A package that was safe when you installed it may later be found to contain a vulnerability.
That does not mean every outdated dependency is automatically exploitable. Risk depends on the vulnerability, the affected version, how the component is used, and the application's exposure.
What developers should do:
- Keep track of your direct and indirect dependencies.
- Use dependency auditing tools.
- Review security advisories for packages you use.
- Update vulnerable components through a tested process.
- Remove dependencies that are no longer needed.
Do not blindly update production systems without testing, but do not ignore security warnings simply because the application still works.
How I Would Start a Safe Security Review
If I were reviewing an application I owned or had explicit permission to test, I would begin with a structured process rather than randomly trying attack techniques.
Step 1: Define the scope.
Identify the application, endpoints, test accounts, environments, and systems you are authorized to assess.
Step 2: Map the application.
Understand the login process, user roles, API endpoints, sensitive data, and important business operations.
Step 3: Test authorization.
Use controlled test accounts to verify that users cannot access one another's records or perform actions beyond their permissions.
Step 4: Review input handling.
Examine how the application processes form submissions, URL parameters, API requests, file uploads, and database queries.
Step 5: Check configuration and dependencies.
Review production settings, exposed files, package versions, and the handling of secrets.
Step 6: Document findings and fix them.
For each verified issue, record the affected component, evidence, potential impact, and recommended remediation. Retest after making changes.
A useful security assessment is not simply a list of things that might be wrong. It should distinguish confirmed findings from suspicions and provide a practical path toward reducing risk.
Where Can You Practise Ethical Hacking Legally?
If you are learning application security, you do not need to target real websites.
Start with environments designed for security training:
- OWASP Juice Shop: A deliberately vulnerable web application for learning common application security weaknesses.
- OWASP WebGoat: A training environment that teaches web application security through guided lessons.
- PortSwigger Web Security Academy: Free web security training materials and interactive labs.
These environments let you learn how vulnerabilities work without putting real users or systems at risk.
Only test systems you own or have explicit authorization to assess. Public accessibility is not permission to probe a website.
Final Thoughts
One thing I want more developers to understand is that a working application is not necessarily a secure application.
A successful login does not prove that authorization is correct. A database query that returns the expected result does not prove that it is safe. A clean deployment does not guarantee that secrets are protected.
Security requires us to think about misuse, unexpected input, incorrect assumptions, and what could happen when one control fails.
You do not have to become a professional penetration tester to improve the security of the software you build.
Start by questioning your assumptions, learning common vulnerability patterns, testing your own applications in controlled environments, and fixing verified weaknesses before they reach production.
The earlier you make security part of development, the less likely it is to become an expensive afterthought.
Let me ask you this:
If you could teach every developer to check just one security issue before deploying an application, what would it be?
Broken access control, SQL injection, exposed secrets, authentication weaknesses, security misconfiguration, or something else?
I'd like to hear your reasoning in the comments.
