Why web-app security is mandatory, not optional
Web applications are critical infrastructure today. Citizen portals, online banking, insurance contracts, energy customer accounts — everything that used to happen at a counter now runs through a browser. That is precisely what makes web applications a preferred target for cyber attacks. Sensitive data, high availability, exposed attack surface: three traits that rarely combine in a single system, and that's exactly why attackers find the combination attractive.
The consequences of a successful attack reach beyond the immediate damage. A data breach doesn't only cost fines and recovery work; it costs trust that has to be rebuilt over years. In regulated industries there's a second layer: BaFin supervision, BSI guidance, OZG, GDPR. A breach isn't merely unpleasant, it is notifiable — with clearly defined consequences.
The traditional reflex of treating security as a job for penetration testers at the end of the project no longer holds up here. Vulnerabilities discovered shortly before go-live are expensive to fix; some force releases to slip. A robust security strategy therefore anchors security in every phase of development — from requirements analysis to patching in production. Tools like OWASP ZAP translate that strategy into engineering practice.
Loss of trust
Data breaches shake customer relationships for years. The financial damage is usually just the visible part.
Regulatory fallout
Notification duties, fines, supervisory action. An incident costs not only money but attention at C-level.
Operational outage
Successful attacks can take systems down for days. In citizen services or for energy providers this has social impact.
Late findings are expensive
A vulnerability found four weeks before release costs many times what the same finding would have cost in the design phase.
The OWASP Top 10 — the threat landscape on two pages
The Open Web Application Security Project (OWASP) has maintained for years a "Top 10" of the most common security risks for web applications — a pragmatic list that distils and prioritises the threat picture. The current edition ranks by frequency and impact:
- Broken access control — access controls that allow unauthorised access. Now the most common entry vector.
- Cryptographic failures — weak or incorrectly applied cryptography: default passwords, outdated algorithms, missing transport encryption.
- Injection — input interpreted as code: SQL injection, cross-site scripting (XSS), command injection.
- Insecure design — architectural weaknesses that late-stage hardening cannot repair.
- Security misconfiguration — default configurations in production, open admin ports, disabled protection headers.
- Vulnerable and outdated components — old libraries, unpatched frameworks, known CVEs.
- Identification and authentication failures — weaknesses in the login process: credential stuffing, weak session management, missing multi-factor authentication.
- Software and data integrity failures — tampered updates, unsigned build artefacts, insecure deserialisation.
- Security logging and monitoring failures — attacks that stay invisible because nobody records anything. Covered in depth in our article on logging in the enterprise.
- Server-side request forgery (SSRF) — applications that query foreign systems on behalf of an attacker.
Two of the most prominent attack patterns deserve a brief detail, because they appear under different names but follow the same principle — the attacker injects something the code blindly trusts:
SQL injection in thirty secondsThe attacker slips SQL code into an input field, e.g. the login form. If the server doesn't parameterise the input cleanly, it executes the code and returns data the attacker should never see. Remedy: parameterised queries or prepared statements — everywhere, no exceptions. No "just not at this one spot".
Cross-site scripting (XSS) in thirty secondsThe attacker plants malicious JavaScript in a page — say in a comment or a profile field. Other users visit the page, their browser executes the code. Result: cookies stolen, sessions hijacked. Remedy: escape every output context-specifically, set a restrictive Content Security Policy, never render raw HTML from user input.
Security across the software development life cycle
A mature security strategy doesn't act in single points but along the whole development cycle — known as the secure software development life cycle (SSDLC). The usual breakdown spans seven phases, each with its own set of measures.
Requirements
Security requirements are gathered alongside business requirements: which data is sensitive, which compliance obligations apply, what level of assurance is needed. This is where the security guideline for the entire project gets anchored — together with the business, not behind its back.
Design
The architecture carries security decisions: access controls, encryption strategies, secure protocols. Threat modelling makes visible which attacks are plausible and how they are blocked — before a single line of code is written.
Implementation
Secure coding guidelines, security-focused code reviews, static analysis (SAST) as a pre-commit hook or IDE integration. Vulnerabilities are ideally caught within minutes of being introduced — not weeks later in an audit.
Testing
Dynamic application security testing (DAST) against the running application. This is where OWASP ZAP comes in: automated scans, manual tests, fuzzing. Security tests run like functional tests — automated, repeatable, with clear thresholds.
Deployment
Infrastructure hardening, secure configuration, secrets management. Build artefacts get signed, pipelines hardened, production environments granted only the minimum necessary privileges (principle of least privilege).
Maintenance and monitoring
Continuous monitoring, patching of known vulnerabilities, regular vulnerability scans against production. Software is never "done secure" — the threat landscape shifts, and what looks robust today may be exposed tomorrow.
Feedback and improvement
Findings from incidents, audits and penetration tests flow back into phase 1. The cycle closes — and this feedback loop is what distinguishes a living security concept from one-off compliance theatre.
The appeal of this model: security is not an extra step at the end, it is a property of every phase. In agile projects this isn't "waterfall through the back door" but a security-aware definition of done per sprint — with tools that create friction in exactly the phase where it raises security.
OWASP ZAP — what the tool delivers
OWASP ZAP (Zed Attack Proxy) is the most influential open-source tool for dynamic security testing of web applications. It is maintained by the OWASP project itself, runs on all major operating systems, can be containerised and automated via a REST API. Architecturally, ZAP is a man-in-the-middle proxy: it sits between browser and web application, intercepts requests, inspects them, and can modify them before forwarding.
From that core, the main capabilities follow:
- Automated scanner. Pre-defined tests against typical weaknesses — injection, XSS, missing headers, weak cookies. Delivers prioritised findings within minutes and is suitable for unattended pipeline runs.
- Manual scanner. Targeted tests in which the tester adjusts requests and observes responses. Catches logical flaws an automated scan can't see — e.g. authorisation checks that happen in the frontend but are missing in the backend.
- Spider. Automatic crawling of the application: every URL, script and API reachable from a root URL ends up in a sitemap. The basis for every subsequent scan.
- Fuzzer. Targeted bombardment of input fields with edge cases — very long strings, special characters, wrong data types, boundary values. Surfaces memory bugs, validation gaps and injection-susceptible spots.
- REST API and CI/CD integration. All functions are accessible programmatically. This is what makes ZAP pipeline-ready: scans run automatically after each deploy to staging and report threshold violations back to the build.
- Authentication and session management. Form-based, token-based or script-based authentication — ZAP follows the application into protected areas and probes session handling for weaknesses such as session fixation or insufficient token rotation.
- WebSockets, extension API and marketplace. Custom add-ons in several programming languages, a marketplace for community extensions, full WebSocket inspection. The tool scales with the use case rather than being overwhelmed by it.
- Report generator. Results in HTML, XML, JSON or Markdown. Findings are prioritised by severity, include reproduction steps and remediation guidance — ready to plug into ticket systems and audit documentation.
ZAP across the SSDLC — where it actually pays off
The leverage from ZAP comes not from a one-off scan before go-live, but from repeated use across multiple phases. Three stations are particularly valuable.
In the development process (CI/CD)
ZAP runs as a job in the build pipeline. On every push to the mainline branch, the application is deployed to staging and a baseline scan runs. If ZAP finds a high-severity issue, the build fails — and the engineer gets the feedback while context is still fresh and the fix costs minutes instead of hours.
One important point: not every scan finding is a bug. False positives are real and need to be curated. A good setup keeps a whitelist of accepted findings with justifications — auditors will later want to see that every ignored finding was deliberately ignored, not accidentally.
In the test phase
This is where the more time-consuming capabilities pay off: full spider runs against the test environment, manual sessions where testers probe authentication flows deliberately, fuzzing campaigns against critical endpoints. These tests don't run on every CI build; they run as an additional gate before each release — as part of a definition of done, not as a nice-to-have.
In production
ZAP also suits continuous vulnerability scans against production — in front of a web application firewall and within agreed maintenance windows. Findings feed into patch prioritisation: critical weaknesses justify out-of-band releases, lower-severity ones flow into the next regular sprint. The link between scan and patch strategy is the actual lever, not the scan itself.
Practical noteA common anti-pattern is "run ZAP once before release". It does find issues, but it's too late — fixing them costs many times what a pipeline-integrated approach would have cost. ZAP unfolds its value only through repetition across the lifecycle.
Recommendation — how we use ZAP in projects
OWASP ZAP is a valuable tool, but it is not a complete security plan. Three pieces of advice from project work that mark the difference between "introduced" and "effective".
- Start small, then expand. First step: ZAP baseline scan as a pipeline job. Two weeks of learning curve, then the first false positives are filtered out and the real findings become visible. Only after that bring in fuzzer, spider and manual tests. Turning on every capability at once drowns the team in noise.
- ZAP findings are not a replacement for requirements. A scanner finds what scanners find — known patterns, known weaknesses. Logical security gaps — for example a clerk who is allowed to close a case without the four-eyes rule kicking in — no tool will catch. That's where threat modelling and code review come in.
- Plan for training. ZAP has a noticeable learning curve. Dropping the tool into a team without onboarding produces frustration and many false positives at the start. A focused one-to-two-day workshop noticeably shortens the warm-up period — and ensures that security is felt as a tool that helps engineers, not as a "burden on the pipeline".
RecommendationIn our projects we treat ZAP as a mandatory tool as soon as a web application handles sensitive data — typical in OZG projects, energy platforms and citizen portals. We handle findings like any other test failure: prioritised, ticketed, with clear owners and deadlines. Security thus becomes not an extra task before release but a measurable property of every iteration — which is exactly the idea of the SSDLC.
