Web application attacks: code, configuration and maintenance

How do attacks on web applications exploit system vulnerabilities?

Web application attacks exploit faulty authentication, insecure input, weak configurations, lack of updates, and poorly separated permissions. Effective protection comes from secure development, hardening, WAF rules, penetration testing, monitoring, patch management and clear response paths, not from a single tool.

Why web applications are still a convenient target

Practical definition: an attack on a web application is the abuse of an error in the code, configuration, authorisation, session, dependencies or the process of maintaining a service available from the Internet. An application exposed to the Internet combines many layers: the user's browser, forms, API, database, sessions, web server and administration panel. If one layer has poor validation, an outdated library, incorrect authorisation, or too broad permissions, an attacker can bypass security measures that look correct on paper. Therefore, the application test must cover code paths, service settings, event logs, secrets, technical accounts and the release process.

What needs to be assessed beyond the application code itself?

Application security doesn't end with fixing a few programming errors. You also need to check the release process, technical accounts, logs, backup and response after detecting an incident. OWASP Top 10 ranks the most important risk classes, but in a company they need to be translated into specific endpoints, roles and decisions of the application owner. Good testing shows not only that the vulnerability exists, but also what process allowed it to exist and how to confirm that it will not return after the next release.

• Input validation, session control, authentication, authorisation and separation of privileges.
• Up-to-date libraries, CMS, plugins, frameworks, container images and server components.
• Configuration of WAF, security headers, TLS, backup, secrets and administrative access.
• Logging of application events and the ability to quickly recreate the attack timeline.

Signals that the problem is systemic, not a one-off

A single vulnerability often exposes a deeper process failure. If a flaw returns after an update, a patch reaches only some environments or nobody can reconstruct the traffic from logs, the issue lies in application maintenance, change delivery and incident response rather than one coding error. Risk increases when the application lacks an accountable owner, tested recovery, controlled access, complete logs or a working escalation route; exposed administration, vulnerable dependencies and leaked secrets then remain open paths into production.

• No application owner who decides on patch priority and risk acceptance.
• No list of dependencies, libraries, plugins, API endpoints and technical accounts.
• No logs from the application, WAF, web server, database and administrative accounts.
• No retest after the fix or no proof that the change has made it to production.

The most common classes of attacks on web applications

An application review separates vulnerability classes such as broken access control, injection and vulnerable dependencies from attack methods and consequences. A botnet is attacker infrastructure, DDoS targets availability, and a webshell may result from a compromise. OWASP Top 10 describes risk categories; concrete test requirements are selected from ASVS.

• SQL Injection and similar input errors can expose customer data or allow query manipulation.
• XSS, malicious URLs and session errors can hijack a user, form or admin panel.
• Webshell and erroneous upload can give the attacker the ability to execute commands on the server.
• Application DDoS overloads expensive endpoints, login, shopping cart, API or database queries.

Why ap­pli­ca­tion main­te­nance is part of security

Companies move sales, customer service, support requests, documents and self-service portals to web applications, so an outage or compromise quickly affects business continuity. Ongoing support should cover the application, server, release process, updates, backups and logs, with a named person responsible for remediation decisions.

• Name the application owner and the person who accepts remediation priority.
• Keep a dependency and plugin inventory so vulnerable components can be located quickly.
• Require retest evidence after a fix reaches production.
• Review logs, WAF rules, backups and administrative accounts on a recurring schedule.

Attack scenarios involving several weaknesses

In practice, an attack often combines several weaknesses: an outdated plug-in, stolen credentials, no MFA, excessive permissions and incomplete monitoring. We therefore analyse the full attack path—from initial access and persistence to business-process impact—and identify the control most likely to break the chain.

How to turn a test into decisions and corrections

A test report should lead to decisions, not merely list vulnerabilities. Each finding needs a priority, an owner, a remediation route, acceptance evidence and a retest trigger. Start by mapping applications, APIs, data classes, exposed administrative paths and deployment owners; then correct the highest-risk code and configuration issues. Acceptance requires a successful retest, evidence that the change reached production, and verified logging, WAF or alert coverage. Remaining architectural risks should be recorded with an accountable owner and formal treatment decision. Set deadlines according to exposure, impact and active exploitation. Urgent mitigation and patch verification must not wait for the entire programme to finish.

• Separate critical gaps from hygiene changes and process improvements.
• Plan corrections to code, server configuration, WAF, backup and permissions.
• Establish regression testing and retesting after patch deployment, especially for forms, APIs, and authorisations.
• Introduce a periodic review of dependencies, secrets, technical accounts and application logs.
• Urgent action based on risk: critical fixes, updating libraries, enforcing MFA for panels and restricting administrative access.
• Strengthen safeguards: WAF configuration, security headers, event logging, backup and secret control.
• After each fix: retest and regression testing, followed by release-process review and documentation of risks accepted by owners.
• Ongoing control: periodic review of dependencies, technical accounts, application logs and code changes.

Evidence after a test or application incident

Application security requires technical material for developers and decision-making material for the business owner. The report should enable you to reproduce the problem, assess the impact on your data or service, and confirm that the fix works after deployment. Retain the tested hosts and endpoints, environment, roles, test window and methodology, confirmed findings, business impact and fix owners. Link each remediation to a release or configuration change and preserve the retest result, accepted exceptions and next test trigger.

• vulnerability description with the endpoint, user role, reproduction steps and impact on data or service
• application, server, WAF and technical account logs with a preserved timeline of events
• commit, release number, change ticket or configuration change that closes the vulnerability
• retest result and a list of risks accepted by the application owner

How to document vulnerabilities clearly for the delivery team and risk owner

A test report should feed the risk register, development backlog and maintenance documentation. The vulnerability record therefore needs the endpoint, user role, reproduction steps, impact on data, associated control, remediation owner and retest evidence. This structure lets the technical team reproduce the problem and gives the business owner enough information to assess impact, priority and safe closure conditions.

• Don't just describe the name of the vulnerability; show the attack path, business condition and impact on confidentiality, integrity or availability.
• Identify affected parts of the environment, such as the API, user session, administrator account, access credentials, WAF and logs.
• Separate code fixes from server configuration, WAF changes, secret rotation, and permission adjustments.
• After retesting, update the vulnerability status so that the backlog and knowledge base do not keep risks already closed.

Current 2026: OWASP Top 10 2025, API and retest proof

In 2026, the security of a web application must be assessed not only by the list of errors in the code, but by the entire maintenance process: permissions model, vulnerable components, API, secrets, logs, WAF, backup, CI/CD environments and decisions of risk owners. OWASP Top 10 2025 and ASVS 5.0 help organise the scope of the test, but the most important thing for management is the proof: the vulnerability was reproduced, assigned, corrected, deployed to the appropriate environment and checked with a retest.

What to prepare before discussing an application test

A well-prepared scope shortens the test time and reduces the risk of accidentally omitting an important function. It is worth collecting information about technology, hosting, test accounts, data processed in the application, environments, integrations and current security measures. This ensures that the test covers business logic and not just an automated scan. Virtline proposes a test scope with retest, evidence and prioritised patch plan.

Virtline Related Services

Application security combines testing, infrastructure, identity protection, monitoring and maintenance. A WAF does not replace an accountable remediation owner, retesting or confirmation that a fix reached production. The services below address different parts of this process.

Attacks that most often form a chain

In a real-world incident, SQL Injection, XSS, webshell, insecure file upload, session hijacking, or a weak admin panel rarely occur in isolation. The attacker links the application bug to the lack of MFA, a vulnerable library, a secret in the repository, poor logging and server access. Therefore, the test report should show the chain of events and the control that will break it.

• Input: vulnerable form, API, panel, file upload, old CMS or compromised account.
• Persistence: webshell, new user, secret, recurring task or configuration change.
• Impact: customer data, service continuity, reputation, cost of downtime and post-breach responsibilities.
• Closure: code fix, server configuration, secret rotation, MFA, WAF, logs and retest.

When to request external application testing

Consider an external test before a major release, after a provider change or incident, or before a customer audit. Define applications, roles and critical processes in scope. The report distinguishes confirmed vulnerabilities from hypotheses and sets remediation priorities and retest conditions.

Acceptance criteria for application security controls

Acceptance must confirm more than task completion. It should name the application version and endpoints reviewed, show which controls operate, record fixed or explicitly accepted findings, and include a clean retest for changed paths. It must also define how representative abuse is logged and escalated, who owns future reviews and which release changes trigger another targeted security assessment.

Contact the application security team

Call +48 12 200 27 10 and share the application URL, technology stack, hosting, authentication model, user roles, exposed APIs, highest-consequence transaction and date of the last security test. We will define the test scope, retest criteria and required evidence.

Sources for the requirements and dates discussed