Business applications are reachable over the web and APIs, work with external services, handle critical data and change constantly. So application security cannot be reduced either to finding vulnerabilities in code or to putting a WAF in front of the application.
Testing before production and traffic protection in production solve different problems.
Blocking is switched on after the application’s real traffic has been analysed.
A vulnerability has to reach the right team and be re-checked.
Hafaza Tech designs and implements application security based on Fortinet FortiWeb, Imperva and OpenText Fortify — from WAF and API protection through to SAST/DAST and embedding checks into development and security operations.
The traffic protection layer. FortiWeb is a WAF for web applications and APIs. It is used in different deployment models: analysis of application traffic, protection against web attacks, policy enforcement and virtual patching.
Particularly logical where the WAF has to work alongside an existing Fortinet infrastructure, though it is also used as a standalone control.
The exact capabilities depend on the model, the version and the licensing.
The traffic protection layer. A specialist vendor in web application and API security. The platform covers WAF and WAAP scenarios: protection of applications and APIs, bot management and other application-level risks.
Suitable where centralised protection is needed for internet-facing applications in an on-premise, cloud or hybrid architecture.
The set of capabilities and the deployment model are chosen for the requirements of the project.
The testing layer. OpenText Fortify works at a different level of the architecture — application security testing and embedding checks into the development process.
It is used for SAST and DAST, application vulnerability analysis, integration with build pipelines and organising the work with findings.
Fortify helps to find a vulnerability, while a WAF reduces the risk of its exploitation until it is fixed. In a mature architecture the two are used together.
The three products are not interchangeable: FortiWeb and Imperva protect traffic in production, Fortify tests applications before release. So the choice is not between them, but about which layer of the architecture the project needs to cover.
Why a WAF is needed
A web application firewall analyses HTTP/S traffic before a request reaches the application and applies security policies to detect and block malicious or non-compliant activity.
Protection against common web attacks
Validation of the protocol and of requests
Signatures and reputation mechanisms
Behavioural mechanisms and anomaly detection
Policies tailored to a specific application
API protection
Bot mitigation
Logging and security telemetry
The exact set of capabilities depends on the platform, the licence and the deployment architecture — this is verified in a pilot, not assumed from the datasheet.
It lowers the chance that a vulnerability is successfully exploited, but it does not fix the vulnerability in the application.
So the right architecture is not “a WAF instead of fixing the application”, but secure development, testing and production protection together. For example, a vulnerability is found by a scanner or in testing, but changing production code takes time: for that period the WAF is used as a compensating control.
Virtual patching shortens the window of risk between finding a vulnerability and actually fixing it. It is particularly useful when the application cannot be updated immediately, the release cycle is long, the vulnerability is in a legacy system, or the risk from the internet has to be reduced quickly.
Virtual patching is a compensating control, not a permanent substitute for a fix. Once the application is fixed, the rule has to be re-checked and removed where appropriate.
A classic WAF historically dealt mostly with web application traffic. Today applications are increasingly built around APIs, microservices and automated interactions, so protection is extending towards Web Application and API Protection.
Browser and client traffic to web interfaces: request validation, protection against common attacks, policies tailored to a specific application.
A separate class of traffic with its own logic: schemas, methods, tokens, object-level access and permitted actions.
Bots and automated interactions — from harmless ones to those abusing the application’s business logic.
What matters for the customer is not the term WAAP in itself, but how much of the application’s real attack surface the chosen platform can actually control.
API security
APIs carry their own risks, related not only to malicious request content but to how the API is used. A mature architecture starts with understanding which APIs exist, who uses them, what data they handle, which actions are allowed and what counts as abnormal behaviour.
Unknown and forgotten APIs
Authentication
Authorisation
Tokens and credentials
Object-level access
Schema and protocol validation
Exposure of sensitive data
Atypical use of an API
Automated abuse
Business-logic scenarios
A WAF can be an important layer of control, but authentication, authorisation and business logic still have to be implemented correctly in the application itself.
Production protection is only one part. Before release you have to reduce the number of vulnerabilities that reach production at all. Several kinds of testing are used for that.
Analyses application code or related artefacts, depending on the technology and the product. It helps find weaknesses closer to the development stage and gives the developer context for a fix.
Tests a running application from the outside. It does not analyse source code: it interacts with the application through its available interfaces and finds vulnerabilities that appear at runtime.
Analyses third-party and open-source components: dependencies, known vulnerabilities, transitive dependencies, a component inventory and supply-chain risk.
An application security program may additionally include secret scanning in code, interactive testing, infrastructure-as-code checks and other tools — depending on the development environment.
The real problem starts once a vulnerability has been found.
If the findings of SAST, DAST, composition analysis and penetration testing live apart, the team quickly gets dozens of repeated alerts about the same thing. So findings are brought into one process: consolidation, de-duplication, prioritisation, assignment of an owner, remediation and verification.
DevSecOps and gates
Security checks become part of the normal development cycle. At the same time, gates that are too strict can simply stop development, so the policy has to account for risk and for the team’s real capacity to fix findings.
Severity of the finding
Exploitability
Criticality of the application
Exposure to the internet
Availability of a fix
Business risk
The goal is not to block as many builds as possible, but to reduce the number of significant vulnerabilities that reach production.
A WAF is designed as part of the application’s working architecture. The specific model depends on the infrastructure and the customer’s requirements, and mistakes here affect not only security but the availability of the service.
TLS and certificates
The WAF has to be able to analyse application traffic after decryption — at the point in the architecture where the design provides for it. So it is decided up front where TLS is terminated, how certificates are managed, how traffic is passed on, whether re-encryption is needed and what requirements apply to protocols and ciphers.
Resilience and clustering
Health checks and failover
Session behaviour during failover
Configuration synchronisation
Recovery procedures
The decision: fail open or fail closed
If strict blocking is switched on without analysing real traffic, the WAF will start blocking the application’s normal operation.
Application traffic can include non-standard requests, file uploads, APIs, web sockets, authentication flows, third-party integrations, mobile applications and automated services. So we use a staged approach.
The application changes all the time. A new release may add URLs, APIs, parameters, an authentication method, file uploads or an external integration. So significant releases have to be part of the WAF lifecycle: a policy that was correct a few months ago does not necessarily match the current version of the application.
A WAF is an important source of telemetry about what actually happens to an application in production.
Context is particularly valuable when a production event can be linked to a vulnerability that is already known: “a known vulnerability plus an exploitation attempt in real traffic” changes the priority of the fix considerably.
Application security becomes markedly more useful when development and production do not exist separately. WAF telemetry shows which parts of the application are actually attacked, while testing results help the SOC understand which events are more dangerous. That creates a loop: test → protect → observe → improve.
Exploitation attempts
Policy violations
Attacks on critical URLs and APIs
Automated and bot activity
Repeated malicious behaviour
Blocked requests
Significant anomalies
Not every application needs the same level of protection. Priority usually goes to internet-facing systems, payment applications, customer portals, mobile back ends, critical APIs and applications handling sensitive data.
01
Assessment
02
Application and API scope
03
Architecture
04
Pilot
05
WAF configuration
06
Application testing
07
Virtual patching
08
SOC integration
09
Regular review
We identify internet-facing applications, the set of APIs, the application architecture, authentication mechanisms, critical data, the current WAF, the testing tools in use, the development pipelines, SOC integration and compliance requirements.
For the WAF we design the traffic flow, the deployment model, TLS termination, throughput, resilience, the architecture behind the WAF, application dependencies, logging and integrations. For testing — repositories, languages and frameworks, build pipelines, test environments, authentication and the process for handling findings.
The WAF pilot tests the full cycle: see the traffic → detect an attack → block safely → keep the application working → fail correctly. Legitimate traffic, typical attacks, APIs, TLS, false positives, latency, compatibility, blocking, failover, logging and ease of administration are all checked.
The testing pilot checks the cycle find → confirm → prioritise → fix → re-check. What is assessed is not the number of vulnerabilities found, but the quality of findings, the false-positive rate, the context given to the developer, coverage of authenticated scenarios, integration into the pipeline and the handling of fixes.
WAF policies are moved to blocking in stages, after real traffic has been analysed. In parallel, virtual patching is configured for vulnerabilities that cannot be fixed immediately.
After go-live, significant events are passed to the SOC, and application changes are taken into account in the lifecycle: new APIs and releases call for policies to be re-checked. Application security is a continuous process, not a one-off configuration.
The choice depends on which layer of the architecture has to be covered. So we evaluate solutions in a pilot rather than from a feature table.
Supported applications and APIs, deployment models, TLS architecture, bot protection.
Virtual patching capabilities, the effort of tuning, latency, resilience, logging.
Delivery of events to the SIEM, fit with the existing infrastructure, licensing and operational complexity.
Supported languages and frameworks, the quality of results, the false-positive rate.
Authenticated testing, integration into the pipeline, handling of findings, developer experience.
Licensing of both layers and the total cost of ownership over the horizon of the project.
Fortify helps to find a vulnerability. FortiWeb and Imperva reduce the risk of its exploitation in production. In a mature architecture these tools complement each other rather than compete.
It should not depend on a single control.
Reduce the number of vulnerabilities before production → find problems in the running application → lower the risk of exploitation → see the real attacks → fix the causes → re-check the result.
Didn’t find the answer to your questions? Send your question below and our support team will answer it soon. We are here to help you with cybersecurity!
Ask a question!
If you want to learn more about our cybersecurity services or are not sure which solutions are right for you, leave a request and our specialists will contact you for a free consultation.
Complementary solutions for comprehensive infrastructure protection and a higher overall level of information security.
Protection of the perimeter and of the network segments the applications run in.
A single process for monitoring and investigating security events.
Remediation of vulnerabilities in the infrastructure the applications run on.
