Web Application Security: 12 Measures Businesses Overlook (A Plain-Language OWASP Guide)

In brief: The great majority of attacks on web applications are not “hacker movie” scenarios but known and preventable weaknesses: insufficient access control, weak authentication, components that are not updated, misconfiguration, unvalidated user input and secret keys left in a code repository or a publicly accessible file. OWASP has classified these weaknesses for years in its “Top 10” list. The 12 measures in this guide (HTTPS, strong authentication, server-side authorization, input validation, secure sessions, secrets management, dependency updates, security headers, file upload control, API protection, logging and monitoring, backups and data minimization) cover most of the risk for most businesses. Security is not a one-off task; it is a continuous part of design, development and maintenance.

Last updated: October 2026

“We're a small business, who would attack us?”

Most attackers do not target a particular business; they scan thousands of sites with automated tools and exploit whatever is open. So even if you are small, these risks are real:

• Leaking of customer data (contact details, orders, identity information)
• Your site being taken over and used for spam or malicious redirects
• The admin panel being taken over and content being changed
• Access to your site being blocked, or a ransom demand
• A “harmful site” warning in search engines and loss of reputation

If you process personal data, you also have data security obligations under KVKK (Turkey's personal data protection law). Security is not only technical but also legal.

What is the OWASP Top 10?

OWASP (the Open Worldwide Application Security Project) is a non-profit community widely used in web application security. The OWASP Top 10 is a classified list of the most critical security risks in web applications. Recurring headings in the list are: broken access control, cryptographic failures, injection, insecure design, security misconfiguration, vulnerable and outdated components, authentication failures, software and data integrity failures, logging and monitoring failures and server-side request forgery. (The list is updated from time to time; see the OWASP page for the current version.)

The 12 measures below are the most practical equivalents of these risks for businesses.

12 basic measures

1. HTTPS (TLS) everywhere, and HSTS

All traffic should be encrypted; HTTP requests should redirect to HTTPS. The HSTS header tells the browser to connect to the site only over HTTPS. Set up automatic renewal and alerts so the certificate is renewed before it expires.

2. Strong authentication

• Passwords are never stored in plain text; use strong, salted, slow hashing algorithms such as bcrypt/argon2.
• Two-factor authentication (MFA) should be mandatory, especially for admin accounts.
• Attempt limiting (rate limiting): Delay or a temporary lock after repeated failed logins.
• The “forgot my password” flow should be secure: single-use, time-limited links; messages that do not reveal whether a user exists.
• Prefer ready-made and tested authentication solutions; avoid writing it from scratch.

3. Server-side authorization (access control)

This is one of the most common and most damaging mistakes: assuming a user cannot reach someone else's data just because they do not see a button in the interface. Every request must be checked on the server:

• Is this user authorized to view/change this record? (E.g. being able to reach someone else's order at /order/1234.)
• Is role-based authorization (customer, employee, admin) applied consistently?
• Is the admin panel clearly protected (authentication + IP restriction if needed)?

4. Input validation and injection prevention

Every piece of data coming from the user, whether a form, a URL parameter, a file name or an API body, must be considered untrusted:

• In database queries use parameterized queries or a trusted ORM; do not insert user input directly into the query text (SQL injection).
• Escape output when rendering to the screen (XSS). Modern UI frameworks do this by default; but use “render raw HTML” features carefully.
• Validate expected format, length and type on the server; validation in the browser is only user convenience.

5. Secure session and cookie management

• Use HttpOnly, Secure and an appropriate SameSite setting on session cookies.
• Renew the session ID on login; invalidate the session on logout.
• Apply CSRF protection (a token, together with SameSite) on state-changing requests.
• Set session durations according to the sensitivity of the work.

6. Managing secret keys

API keys, database passwords and service accounts:

• Must not be placed in the code repository or in client-side code. Any code sent to the browser can be read by anyone.
• Should be stored in environment variables or a secrets-management service.
• Should be rotatable when needed; renewed immediately if a leak is suspected.
• High-privilege keys (e.g. “service role” keys) should be used only on the server and never sent to the user.
• Development, test and live environments should use separate keys.

7. Keep dependencies up to date

Modern applications rely on hundreds of open-source libraries; known vulnerabilities in them are among the paths attackers use most.

• Regular scanning (dependency security scanning) and updating of the packages in use,
• Removing unused packages,
• Keeping a lockfile and releasing updates after testing.

This is the most important preventive part of maintenance; you can find details in our software maintenance and support guide.

8. Security headers

A few headers sent by the server provide important protection on the browser side:

You can explore security headers in MDN's security guide. A correctly set CSP should be tailored to the sources the application actually uses.

9. File upload security

If users can upload files (profile picture, document, CV):

• Verify the file type and size on the server; do not rely on the extension alone.
• Store files outside the web root or in a separate storage service; prevent them from being executable.
• Assign random file names; keep the original name only for display.
• Run malware scanning if needed.

10. API and integration security

Mobile apps, panels or third-party integrations talk through APIs. In the API too, do authentication and authorization on every request; also:

• Limit abuse with rate limiting.
• Restrict CORS to the sources actually needed; do not leave it “open to everywhere.”
• Do not leak technical detail (database structure, file paths) in error messages.
• Protect webhooks with signature verification.

11. Logging, monitoring and alerts

To be able to understand what happened when there is an attack or an error:

• Login attempts, authorization failures and critical operations (deletion, payment, permission changes) should be recorded.
• Logs must not contain sensitive data such as passwords and card numbers.
• Alerts should be generated on unusual behavior (many failed logins, a sudden rise in errors).
• Logs should be kept long enough and must not be alterable without authorization.

12. Backups and data minimization

• Regular backups whose restoration has been tested save the day in a ransomware attack or data corruption.
• Data minimization: Do not collect or keep data you do not really need; data you do not store cannot leak.
• When storing sensitive data (personal data, identity, health, etc.), apply encryption and access restrictions.
• Define data retention periods.

If you have added AI features

AI features such as chatbots, assistants or document analysis bring new risks: steering the model through user input (prompt injection), sensitive data leaking into answers, excessive access to tools/actions. OWASP publishes a separate LLM Top 10 list on this. For details, see our AI chatbot guide and RAG article.

8 security questions to ask your software vendor

1. How do you design authentication and authorization? Is MFA provided for the admin panel?
2. How do you validate user input and protect against injection?
3. Where and how are secret keys stored? Are environments separate?
4. How do you track and update dependencies?
5. Which security headers and HTTPS settings do you apply?
6. How do backup frequency and restore testing work?
7. How do logging and monitoring work? In a security incident, who is notified and how quickly?
8. Is pre-launch security testing (scanning, code review, a penetration test if needed) performed?

If you cannot get clear answers to these questions when choosing a vendor, also review our 15 questions to ask a software company.

If a security incident happens: the first 24-hour plan

Knowing in advance what to do when an incident occurs matters as much as taking precautions:

1. Stay calm and inform the right people. Who decides, who makes the technical response?
2. Limit the scope. Isolate affected accounts/systems; temporarily put the site into maintenance if needed.
3. Preserve the evidence. Save logs and system state before deleting; if cleanup is done without understanding the cause, it will recur.
4. Change keys and passwords. Renew all secrets that may have leaked; end sessions.
5. Close the hole. Find and fix the root cause; you may need to return to a clean version from a backup.
6. Evaluate legal obligations. In a personal data breach there are notification deadlines to the Board and to the persons concerned (the Board's decisions provide for 72 hours); consult your legal adviser.
7. Learn. Do a post-incident review and update your measures.

7 most common security mistakes

1. Treating security as a “last job before launch”
2. Doing authorization checks only in the interface
3. Leaving admin panel access with a single password
4. Putting API keys in client code or the repository
5. Postponing updates out of fear that “something will break”
6. Taking backups but never trying a restore
7. Using the same passwords/keys in test and live environments

How Aktaş Digital approaches security

In the web applications we develop, we treat basic measures such as authentication, role-based authorization, input validation, secure session management, security headers, secrets management and backups as part of design and development; after launch we offer support plans for updates and monitoring. This matters especially in projects that process customer and business data, such as web applications, SaaS platform development, CRM and ERP.

For a quick first look at the externally visible technical state of your current site you can use our free Website Review tool; but this tool is not a substitute for a comprehensive security test. If you want to discuss security requirements for your project, you can write to us through our quote form.

Frequently Asked Questions

Is an SSL certificate enough for security?

No. SSL/TLS encrypts the data between browser and server; but it does not solve weaknesses inside the application (authorization, injection, weak passwords, outdated components). HTTPS is necessary but not sufficient on its own.

Is a penetration test necessary?

It is recommended before launch and at set intervals for systems that process personal data, take payments or do critical work. For a small brochure site, basic measures and automated scans are often enough. Set the scope according to the system's criticality.

Are WordPress or ready-made systems less secure?

Both approaches can be secure or insecure. What matters is that updates are applied, the number of plugins is kept limited and trusted, and authentication is strong and backups are regular. The same discipline is needed in custom software.

What is my responsibility if I leak customer data?

In personal data leaks, obligations such as notification and administrative sanctions may arise under KVKK. Because details change with your situation, consult a legal adviser and document your preventive security measures.

How do I know whether I have a security hole?

Use regular dependency scans, code review, automated security scanners and, if needed, an expert penetration test. Also watch for unusual activity in log records.

How should I set the security budget?

According to the criticality of the data and system being protected. Basic measures (HTTPS, strong authentication, updates, backups) are cheap and indispensable for almost every project; additional testing and monitoring increase with risk.

Conclusion

Web application security is not “a big budget” but the discipline of applying the basic measures consistently. HTTPS, strong authentication, server-side authorization, input validation, secrets management, updates, security headers, logging and backups close most of your risk. The first thing you can do today: turn on two-factor authentication for your admin accounts and list where the secret keys in your system are kept.