Every website that takes user input is a potential target for an attacker.
You might think your app is too small or too new to get noticed, but attackers use tools to scan the web for common security mistakes.
If your site is online and has a login form, a search box, or a database, it’s already being tested.
But here’s the good news: you don’t need to be a cybersecurity expert to protect your app. You just need to understand how these attacks work and write safer code.
Let’s go through ten of the most common ways hackers break into web apps—and how to fix each one, with clear examples.
Here’s what we’ll cover:
SQL Injection
Hackers exploit this when your app lets them send raw SQL commands directly to your database. Here’s an insecure example in PHP:
$sql = <span class="hljs-string">"SELECT * FROM users WHERE username = '<span class="hljs-subst">$username</span>' AND password = '<span class="hljs-subst">$password</span>'"</span>;
If a user enters this as the username:
' OR 1=1 --
The query becomes:
<span class="hljs-keyword">SELECT</span> * <span class="hljs-keyword">FROM</span> <span class="hljs-keyword">users</span> <span class="hljs-keyword">WHERE</span> username = <span class="hljs-string">''</span> <span class="hljs-keyword">OR</span> <span class="hljs-number">1</span>=<span class="hljs-number">1</span> <span class="hljs-comment">--' AND password = '';</span>
This returns all users – because 1=1 is always true. That means anyone can log in without knowing a password.
This is called string-building, where user input is directly inserted into the SQL command. It treats the input as part of the code, not just data.
The fix: use prepared statements
Prepared statements separate code from data. The SQL command is defined once, and user values are passed separately – so they can’t break the logic.
Here’s the same query using PHP with PDO:
$stmt = $pdo->prepare(<span class="hljs-string">"SELECT * FROM users WHERE username = ? AND password = ?"</span>);
$stmt->execute([$username, $password]);
This makes your code immune to SQL injection – even if a user tries to inject malicious input.
Cross-Site Scripting (XSS)
Let’s say your site shows comments. If someone posts this:
<span class="hljs-tag"><<span class="hljs-name">script</span>></span><span class="javascript">alert(<span class="hljs-string">'Gotcha!'</span>);</span><span class="hljs-tag"></<span class="hljs-name">script</span>></span>
And your site displays it as-is, every visitor sees a popup. That’s a basic XSS attack. A real attacker could do much worse – like stealing session cookies or redirecting users to fake login pages.
The fix: escape what you show
Escaping means converting special characters like < and > into harmless text.
In PHP:
<span class="hljs-keyword">echo</span> htmlspecialchars($userInput, ENT_QUOTES, <span class="hljs-string">'UTF-8'</span>);
In JavaScript, you can use libraries like DOMPurify:
<span class="hljs-keyword">const</span> safeHTML = DOMPurify.sanitize(userInput);
Never trust user input – especially when putting it back into your HTML.
Cross-Site Request Forgery (CSRF)
CSRF tricks a logged-in user’s browser into making an unwanted request to your site – without their knowledge.
Here’s how it works: a user logs into your app and then visits a malicious site. That site contains code like:
<span class="hljs-tag"><<span class="hljs-name">img</span> <span class="hljs-attr">src</span>=<span class="hljs-string">"https://yourapp.com/delete-account"</span> /></span>
Since the user is already logged in, their browser sends the request – with cookies and all. If your app doesn’t check for CSRF, it assumes the user wanted to delete their account.
The fix: use CSRF tokens
These are unique, secret values included in forms:
<span class="hljs-tag"><<span class="hljs-name">input</span> <span class="hljs-attr">type</span>=<span class="hljs-string">"hidden"</span> <span class="hljs-attr">name</span>=<span class="hljs-string">"csrf_token"</span> <span class="hljs-attr">value</span>=<span class="hljs-string">"abc123"</span>></span>
Your server must check this token on every request. If it’s missing or incorrect, reject the request. Most frameworks (like Laravel or Django) do this automatically.
Broken or Weak Authentication
If your login system is too simple, it’s an easy target.
Common mistake: storing passwords in plain text:
file_put_contents(<span class="hljs-string">'users.txt'</span>, <span class="hljs-string">"<span class="hljs-subst">$username</span>:<span class="hljs-subst">$password</span>n"</span>);
If this file leaks, all user accounts are exposed.
The fix: hash passwords
$hash = password_hash($password, PASSWORD_DEFAULT);
And to check them later:
<span class="hljs-keyword">if</span> (password_verify($password, $storedHash)) {
<span class="hljs-comment">// Login success</span>
}
Other critical fixes:
-
Rate limit login attempts: Block or delay after 5 failed tries.
-
Add multi-factor authentication (MFA): Send a one-time code via email or app.
-
Use strong password policies: Require longer passwords with a mix of characters.
Each step makes brute-force attacks harder and protects user accounts.
Insecure Direct Object References (IDOR)
Suppose your site has this URL:
/invoice?id=123
A hacker tries:
/invoice?id=124
Suddenly, they can see someone else’s invoice.
The fix: verify ownership
$stmt = $pdo->prepare(<span class="hljs-string">"SELECT * FROM invoices WHERE id = ? AND user_id = ?"</span>);
$stmt->execute([$invoiceId, $loggedInUserId]);
Always confirm the logged-in user owns the data they’re trying to access.
Security Misconfiguration
This refers to using insecure default settings or forgetting to disable things that shouldn’t be public.
Examples include:
-
Leaving error messages on in production (
display_errors = 1) -
Exposing admin panels or debug tools
-
Using default passwords or outdated software
These aren’t bugs in your code – but they’re just as dangerous.
The fix: disable detailed error reporting in production:
ini_set(<span class="hljs-string">'display_errors'</span>, <span class="hljs-number">0</span>);
And secure admin tools with passwords, IP allowlists, or move them behind a VPN or private path.
Sensitive Data Exposure
If you send user data over HTTP instead of HTTPS, anyone on the network can read it – like passwords or credit card numbers.
Example of unsafe code:
file_put_contents(<span class="hljs-string">'logs.txt'</span>, <span class="hljs-string">"User: <span class="hljs-subst">$username</span>, Password: <span class="hljs-subst">$password</span>"</span>);
If that log file is exposed, all passwords are leaked.
Fixes:
-
Use HTTPS everywhere. Tools like Let’s Encrypt make it free and easy.
-
Never store passwords in logs.
-
Encrypt sensitive data at rest, especially if it’s personally identifiable info (PII) or financial data.
Using Outdated Libraries
Most apps use external libraries. If one has a known vulnerability, attackers can exploit it – even if your code is perfect.
To protect yourself:
- Regularly update dependencies. In Node.js:
npm audit fix
- In PHP:
composer update
- Replace unmaintained libraries with safer alternatives.
Broken Access Control
Some apps try to control access just by hiding buttons on the UI.
Example: A user isn’t shown the “delete post” button – but they manually send a request like:
<span class="hljs-attribute">POST /delete-post?id=5</span>
If the backend doesn’t check permissions, the request goes through.
The fix: enforce access control on the backend
<span class="hljs-keyword">if</span> ($user->role !== <span class="hljs-string">'admin'</span>) {
http_response_code(<span class="hljs-number">403</span>);
<span class="hljs-keyword">exit</span>;
}
Don’t rely on the front-end to block actions. The server must check every request and confirm the user is allowed to perform the action.
No Logging or Monitoring
If something suspicious happens and you don’t have logs, you’ll never know.
Example log entry (in Laravel):
Log::info(<span class="hljs-string">'User login'</span>, [<span class="hljs-string">'user_id'</span> => $user->id]);
Set up alerts for suspicious behavior – like 100 failed logins in 10 minutes. Use monitoring tools like Sentry, Datadog, or ELK Stack to watch your app in real time.
If you don’t track what’s happening, you can’t stop it when things go wrong.
Conclusion
Hackers don’t need advanced tools. Most just look for easy wins – unescaped forms, plaintext passwords, outdated libraries, or exposed admin areas.
If you follow the basics in this guide, you’ll block 90% of those attacks.
You don’t need to fix everything today. Start with one item. Escape user input. Use HTTPS. Add CSRF protection. Each fix makes your app a little safer.
Want to learn more? Get strong basics in offensive security—take the Security Starter course.
Source: freeCodeCamp Programming Tutorials: Python, JavaScript, Git & MoreÂ