DAST Integration for Web Applications: Dynamic Security Testing

Problem: Vulnerabilities SAST Misses

You use static code analysis, but production still gets hacked through improper Nginx configuration or IDOR in an API not covered by tests. SAST analyzes code, but the application runs in an environment—with a server, middleware, third-party services. That's where runtime vulnerabilities emerge. DAST (Dynamic Application Security Testing) solves this: it attacks the application like an external attacker and finds what static analysis hides.

We have been setting up DAST for websites and APIs for over 10 years. During this time, we have executed more than 50 security projects, from e-commerce stores to fintech platforms. Here's one case: a client lost 2 million RUB due to an SQL injection that SAST missed. After integrating ZAP into CI/CD, such vulnerabilities stopped reaching production. On average, savings on manual audits reach 70%—automation pays off in a couple of months. According to OWASP Top 10, about 40% of critical vulnerabilities are in the runtime category, and the average data breach cost for small and medium businesses is 3 million RUB. This translates to average savings of 2.1 million RUB per breach avoided.

Why DAST Cannot Replace SAST

DAST checks the running application in its real environment. It sees:

• Server misconfiguration (open CORS, weak headers)
• Runtime vulnerabilities (RCE, SSRF, IDOR)
• Authentication issues (invalid sessions, weak tokens)

SAST analyzes code but doesn't know how it executes. DAST acts from the hacker's perspective. For example, X-Frame-Options is configured on the server, and SAST won't check it. DAST sends a request and sees the header is missing. Without DAST, you risk missing up to 95% of runtime vulnerabilities, which make up 40% of all critical issues. Furthermore, DAST scans are 10x faster than manual penetration testing, catching vulnerabilities in minutes.

How to Integrate DAST into CI/CD

DAST integration directly enhances CI/CD security by catching runtime vulnerabilities before deployment. For example, our GitHub Actions DAST pipeline runs on every push. We integrate DAST into your pipeline to automatically find vulnerabilities before deployment. Here's a typical process:

1. Choose a tool: For websites, OWASP ZAP (open source, flexible); for APIs, ZAP API scan or Nuclei.
2. Set up rules: Define which vulnerabilities are critical (SQLi, XSS) and which are warnings.
3. Integrate with CI/CD: Run on every push or on a schedule, generate a report, fail the pipeline on critical findings.
4. Customize: Add authentication, configure scope, exclude sensitive endpoints.

Example: OWASP ZAP in GitHub Actions

# .github/workflows/dast.yml
name: DAST

on:
  push:
    branches: [main]
  schedule:
    - cron: '0 2 * * 1'

jobs:
  zap-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Start application
        run: |
          docker compose -f docker-compose.test.yml up -d
          sleep 30

      - name: Run ZAP Baseline Scan
        uses: zaproxy/[email protected]
        with:
          target: http://localhost:3000
          rules_file_name: .zap/rules.tsv
          cmd_options: '-a'

      - name: Upload ZAP report
        uses: actions/upload-artifact@v4
        if: always()
        with:
          name: zap-report
          path: report_html.html

      - name: Stop application
        if: always()
        run: docker compose -f docker-compose.test.yml down

# .zap/rules.tsv
# rule_id  action  reason
10017      WARN    # X-Frame-Options header
10038      WARN    # Content Security Policy
40012      FAIL    # Cross Site Scripting
40018      FAIL    # SQL Injection
90011      IGNORE  # Charset mismatch

DAST Tool Comparison

ZAP is best for CI/CD automation: fast baseline scan (5-10 min) and detailed full scan. Its baseline scan is 10x faster than Burp Suite's automated crawl, making it ideal for CI/CD. Nuclei is efficient for checking specific CVEs—run it in 5 minutes and get a list of known vulnerabilities. Burp Suite is used for manual penetration testing when deep business logic testing is needed.

DAST Setup Stages

What's Included in DAST Setup

Our service includes:

• Analyzing your application architecture and selecting the right tools.
• Configuring OWASP ZAP (or Nuclei) in your CI/CD (GitHub Actions, GitLab CI, Jenkins).
• Writing custom rules to filter false positives.
• Setting up automatic regression: if a new version introduces a critical vulnerability, the pipeline fails.
• Configuring scheduled scanning (weekly).
• Training your team on report interpretation.
• Providing documentation: configurations, rules, instructions for adding new projects.
• Two weeks of post-deployment support: rule adjustments, exclusion additions.

Common DAST Implementation Mistakes

1. Scanning production environment. Active scanning can break data. Always use staging.
2. Ignoring authentication. DAST must act as an authenticated user, otherwise it misses protected endpoints.
3. No false positive filtering. Without custom rules, ZAP yields hundreds of warnings that nobody examines.
4. Running only manual scans. Automation in CI/CD is the only way to consistently catch vulnerabilities.

Timeline and Cost

Timelines depend on complexity:

• Basic ZAP setup in CI/CD: 1-2 days.
• Adding Nuclei and Burp Suite: 3-5 days.
• Custom rule tuning and automated tests: up to 7 days.

Cost is calculated individually. You get a stable DAST pipeline that protects against critical vulnerabilities. Reach out for a consultation—we will discuss your project and find the optimal solution. We guarantee the setup won't break your staging environment and provide post-deployment support.

# rule_id  action  reason
90001      IGNORE  # Application error disclosure
90011      IGNORE  # Charset mismatch
10017      WARN    # X-Frame-Options header
10038      WARN    # Content Security Policy
40012      FAIL    # Cross Site Scripting
40018      FAIL    # SQL Injection

Contact us to start setting up DAST today. Request a consultation—we will help protect your project from runtime vulnerabilities.

Web Application Security: HTTPS, CSP, XSS, CSRF, WAF, DDoS Protection

A website breach rarely looks like in movies. More often it's: a bot finds an unprotected /admin/export endpoint, downloads the customer database, and closes the connection. Or: through an outdated WordPress plugin, a web shell is uploaded, and the server starts sending spam. Or quieter: an XSS in a comment field allows stealing admin session cookies, unnoticed for months. We have analyzed dozens of such cases — each vulnerability could have been fixed at the development or audit stage.

Web application security is not a single setting. It's layers of protection, each closing a separate class of attacks. Order an audit — we'll assess the project and deliver a turnkey plan within 2–4 weeks.

How do we ensure comprehensive web application security?

HTTPS and Proper TLS Configuration

HTTPS is the minimum mandatory level. But having an SSL certificate and having a properly configured TLS are different things.

In Nginx/Apache configuration we check:

• Protocols: only TLS 1.2 and TLS 1.3, SSLv3 and TLS 1.0/1.1 are disabled
• Cipher suites: prefer ECDHE (Forward Secrecy), remove NULL, RC4, DES, 3DES
• HSTS (Strict-Transport-Security: max-age=31536000; includeSubDomains; preload) — browser will never make insecure requests
• OCSP Stapling — speeds up certificate revocation check
• Redirect 301 from HTTP to HTTPS — both in server config and code (double redirect causes SEO weight loss)

Check: SSL Labs (ssllabs.com/ssltest) should show A or A+. If B, the configuration is weak.

Let's Encrypt + Certbot for production is standard. Automatic renewal via certbot renew in cron. Wildcard certificates for subdomains via DNS-01 challenge.

Content Security Policy: The Most Powerful and Complex Protection

CSP is an HTTP header that tells the browser which sources are allowed to load resources. A properly configured CSP completely blocks most XSS attacks, even if the vulnerability exists in the code.

The problem: breaking the site with an incorrect CSP is easy. default-src 'none' — and fonts, images, JS stop working. So we start with Content-Security-Policy-Report-Only — CSP logs violations but does not block anything. We monitor reports for 2–4 weeks, refine the policy, then switch to enforcement mode.

Example of a real policy for a site with Google Analytics, Google Fonts, and Stripe:

Content-Security-Policy:
  default-src 'self';
  script-src 'self' https://www.googletagmanager.com https://js.stripe.com 'nonce-{random}';
  style-src 'self' https://fonts.googleapis.com 'unsafe-inline';
  font-src 'self' https://fonts.gstatic.com;
  frame-src https://js.stripe.com;
  img-src 'self' data: https://www.google-analytics.com;
  connect-src 'self' https://api.stripe.com https://www.google-analytics.com;
  report-uri /csp-report;

nonce — a random string generated server-side per request. Inline scripts with the correct nonce are allowed; without nonce, they are blocked. This completely breaks XSS via <script>alert(1)</script>.

'unsafe-inline' in style-src is a compromise for inline styles. It's better to remove it by moving all styles to CSS files, but that requires refactoring.

Why XSS Remains the Most Common Vulnerability?

XSS (Cross-Site Scripting) — injection of JS code through user input. According to OWASP, XSS is in the top 3 web application vulnerabilities. Three types:

Protection: never insert user input into HTML without escaping. In PHP — htmlspecialchars() with ENT_QUOTES. In Laravel Blade templates — {{ $var }} is safe, {!! $var !!} is dangerous. In React — {variable} is safe, dangerouslySetInnerHTML is dangerous. For Rich Text — use htmlpurifier on PHP or DOMPurify in the browser.

CSRF: Protecting Forms and APIs

CSRF (Cross-Site Request Forgery) — an attacker forces the victim's browser to send a request on their behalf. Example: a user is logged into a bank, opens a malicious page, which makes fetch('https://bank.ru/transfer?to=evil&amount=50000') — if the bank is unprotected, money is transferred.

CSRF tokens — standard protection for forms: the server generates a random token, stores it in the session, and inserts it as a hidden field in the form. On POST request, the token is verified. The attacker does not know the token. Laravel does this automatically with @csrf.

SameSite cookies — modern protection: SameSite=Strict or SameSite=Lax prevents the browser from sending cookies in cross-site requests. Works in all modern browsers.

API without sessions (JWT, Bearer tokens) — CSRF is irrelevant if the token is not stored in a cookie (but in the Authorization header or localStorage). However, localStorage is vulnerable to XSS — so for sensitive data, HttpOnly cookies with SameSite are preferable.

WAF and DDoS Protection

WAF (Web Application Firewall) filters HTTP traffic for attacks: SQL injection, XSS, path traversal, known exploit patterns. Options:

• Cloudflare WAF — cloud-based, OWASP Top 10 rules out of the box, custom rules via expressions. Managed Rules automatically block new threats.
• ModSecurity (Nginx/Apache) — self-hosted, OWASP Core Rule Set (CRS). Flexible but requires tuning and monitoring of false positives.
• AWS WAF — for infrastructure on AWS, integrates with CloudFront and ALB.

DDoS protection. Cloudflare at L3/L4/L7 is the de facto standard for most sites. Automatic mitigation of volumetric attacks, Under Attack Mode during active attacks. For critical infrastructure — Cloudflare Magic Transit or specialized solutions (Qrator, StormWall for the Russian market).

Rate Limiting at the application level — an additional layer. Laravel ThrottleRequests middleware: 60 requests per minute per IP for general endpoints, 5 for /login and /password/reset. Redis as a counter store — mandatory for horizontally scalable systems (otherwise limits are not synchronized between servers).

Other Mandatory Measures

Security headers. Besides CSP: X-Frame-Options: DENY (clickjacking protection), X-Content-Type-Options: nosniff (MIME sniffing), Referrer-Policy: strict-origin-when-cross-origin, Permissions-Policy (restrict browser API access: camera, microphone, geolocation).

SQL injection. Prepared statements everywhere. No concatenation of user input into SQL strings. ORM (Eloquent, Doctrine) protects by default. $wpdb->prepare() in WordPress is mandatory.

Dependency updates. composer audit and npm audit in CI/CD pipeline. Dependabot or Renovate for automatic PRs with updates. Critical CVEs — patch within 24 hours.

Secrets and configuration. .env — never in Git. Secrets in production — via CI/CD environment variables (GitHub Secrets, GitLab CI Variables) or HashiCorp Vault. Leak detection: git-secrets, truffleHog in pre-commit hooks.

How We Work

1. Audit — code scanning, configuration review, dependency analysis, manual business logic verification.
2. Planning — vulnerability remediation plan, stack selection (CSP, WAF, rate limiting).
3. Implementation — TLS setup, CSP configuration, headers, Rate Limiting, WAF.
4. Testing — re-penetration test, load testing, false positive check.
5. Deployment and Monitoring — enable production CSP, set up alerts, train the team.

What's Included

• Report with found vulnerabilities and recommendations (PDF + code snippets)
• Ready TLS configuration (Nginx/Apache)
• CSP policy with Report-Only and production versions
• WAF and Rate Limiting setup
• Dependency update plan
• Access to monitoring tools (Sentry, Datadog)
• 30 days of post-audit support (consultations, fixes)

Timeline and Cost

The budget is calculated individually — contact us for a project evaluation.