Web app security: what to watch out for?
Web app security is about several layers that together stop attackers from getting in or doing damage: secure authentication (strong logins and MFA), tight authorisation following least privilege, protection against the well-known OWASP risks such as injection and XSS, thorough input validation, logging and monitoring to spot attacks, secure hosting, and periodic maintenance with pentests. No single measure stands alone — it's the whole that protects your application and your users' data. Below we walk through the key points one by one.
Secure authentication: strong logins and MFA
Authentication is the front door of your web application. Start with strong password rules and never store passwords in readable form, but hashed with a modern, slow algorithm. Limit the number of login attempts to stop brute-force attacks, and be careful with error messages that reveal whether an account exists. The biggest improvement is multi-factor authentication (MFA): an extra step beside the password, for example a code from an app. Even if a password leaks, MFA keeps the attacker out. Also ensure secure session management — short sessions, secure cookies and automatic logout — so a hijacked session doesn't grant free access.
Roles and permissions: authorisation by least privilege
Authentication determines who someone is; authorisation determines what they may do. Apply the principle of least privilege: give each user and each component only the permissions strictly needed, no more. Work with clear roles (for example reader, editor, administrator) and check on every sensitive action, on the server side, whether the user is actually authorised — never rely solely on what the interface hides. A common mistake is that the button disappears but the underlying request still works. Good authorisation prevents an ordinary user from reaching another user's, or the administrator's, data and functions.
The OWASP risks: injection and XSS
The OWASP Top 10 summarises the most common web risks, and two of them come up again and again. Injection (such as SQL injection) occurs when user input ends up directly in a database query; the solution is to use parameterised queries so data is never executed as code. Cross-site scripting (XSS) occurs when input is shown in the page unfiltered, allowing an attacker to inject malicious scripts; protect yourself by encoding output correctly and setting a Content Security Policy. Other OWASP risks — weak access control, insecure configuration, vulnerable components — deserve equal attention. The principle is always the same: trust no input and keep everything that comes from outside strictly separate from your code.
Input validation: never trust the input
Almost every attack starts with input the application didn't expect. So the rule is: validate and sanitise all input on the server side, whether it comes from a form, a URL, an API or an upload. Validation in the browser is nice for the user but offers no security — an attacker bypasses it effortlessly. Check type, length, format and range, use a whitelist of allowed values where possible, and be extra strict with file uploads (type, size and storage location). Then encode the output depending on the context (HTML, URL, JavaScript). In one move you rule out a large part of the injection and XSS risks.
Logging, monitoring and secure hosting
You can only respond to what you can see. Good logging records who did what and when — especially failed logins, permission changes and suspicious requests — without logging sensitive data such as passwords. With monitoring and alerts you notice abnormal behaviour in time, instead of only after the breach. Underneath lies the foundation: secure hosting. A well-configured server environment with firewalls, enforced HTTPS, separated environments, timely patches and automatic backups removes a large part of the risk. Read more about our secure hosting, which is built with these measures.
Periodic maintenance and pentests
Security is not a one-off project but an ongoing process. Software ages, new vulnerabilities are discovered and your application grows. So keep dependencies and frameworks up to date, follow security advisories and schedule regular maintenance. In addition, have a pentest (penetration test) and code review carried out periodically: an independent specialist then actively tries to break in and finds weak spots before an attacker does. At Secrotec we build web applications with security baked in from the design, and we audit existing apps on these points. See also how we deliver websites securely.
Frequently asked questions
Short, direct answers to the most common questions.
Several layers at once: secure authentication with MFA, tight authorisation by least privilege, protection against OWASP risks such as injection and XSS, thorough server-side input validation, logging and monitoring, secure hosting, and periodic maintenance with pentests. No single measure is enough on its own — it's the interplay that protects your application and user data.
MFA adds a second step beside the password, for example a code from an authenticator app. It matters because passwords leak, get reused or guessed. With MFA, an attacker who only has the password still can't get in. It is one of the most effective and relatively simple measures to protect accounts.
The OWASP Top 10 is a widely supported list of the most common and impactful security risks for web applications, such as injection, cross-site scripting (XSS) and weak access control. It is an excellent starting point to test your application against. A secure web app structurally accounts for these risks, from design to maintenance.
Because validation in the browser can be bypassed effortlessly by an attacker. Only server-side validation offers real protection. Check the type, length, format and range of all input, use a whitelist where possible and encode output per context. This prevents a large part of injection and XSS attacks, which almost always start with unexpected input.
Authentication establishes who someone is (logging in); authorisation determines what they are then allowed to do. Both are needed. A secure web app checks on every sensitive action, on the server side, whether the user is authorised, following the principle of least privilege — minimal permissions, no more than strictly necessary.
Security is ongoing. Keep software and dependencies continuously up to date and have a pentest and code review carried out periodically — for example yearly and after major changes. That way an independent specialist finds weak spots before an attacker does. Combine this with regular maintenance so new vulnerabilities are closed quickly.
Want your web app built or audited securely?
We build web applications with security baked in and run pentests and code reviews on existing apps. Tell us what you need — you'll get honest advice.
