Application Security

Vad är DAST (Dynamisk applikationssäkerhetstestning)

Dynamisk applikationssäkerhetstestning, eller DAST, är ett sätt att kontrollera en applikations säkerhet medan den körs. Till skillnad från SAST, som tittar på källkoden, testar DAST säkerheten genom att simulera verkliga attacker som SQL-injektion och Cross-Site Scripting (XSS) i en live-miljö.

Vad är DAST (Dynamisk applikationssäkerhetstestning)?

Dynamisk applikationssäkerhetstestning, eller DAST, är ett sätt att kontrollera en applikations säkerhet medan den körs. Till skillnad från SAST, som tittar på källkoden, testar DAST säkerheten genom att simulera verkliga attacker som SQL-injektion och Cross-Site Scripting (XSS) i en live-miljö.

DAST kallas ofta för Black Box Testing eftersom det kör ett säkerhetstest från utsidan.

Varför DAST är viktigt inom cybersäkerhet

Vissa säkerhetsproblem uppstår endast när applikationen är live, särskilt problem kopplade till körning, beteende eller användarvalidering. DAST hjälper organisationer att:

  • Upptäcka säkerhetsproblem som missas av SAST-verktyget.
  • Utvärdera applikationen i verkliga omständigheter, inklusive front-end och API.
  • Stärka applikationssäkerheten mot webbapplikationsattacker.

Hur DAST fungerar

  • Kör applikationen i test- eller stagingmiljön.
  • Skicka skadlig eller oväntad input (som skapade URL
    eller nyttolaster).
  • Analysera applikationens respons för att upptäcka sårbarheter.
  • Skapa rapporter med förslag på åtgärder (i Plexicus, ännu bättre, det automatiserar åtgärder).

Vanliga sårbarheter som upptäcks av DAST

  • SQL-injektion: angripare infogar skadlig SQL-kod i databasfrågor
  • Cross-Site Scripting (XSS): skadliga skript injiceras i webbplatser som körs i användarnas webbläsare.
  • Osäkra serverkonfigurationer
  • Bruten autentisering eller sessionshantering
  • Exponering av känslig data i felmeddelanden

Fördelar med DAST

  • täcker säkerhetsbrister som missas av SAST-verktyg
  • Simulerar verkliga attacker.
  • fungerar utan åtkomst till källkoden
  • stödjer efterlevnad som PCI DSS, HIPAA och andra ramverk.

Exempel

I en DAST-skanning hittar verktyget ett säkerhetsproblem i ett inloggningsformulär som inte korrekt kontrollerar vad användarna skriver in. När verktyget anger ett speciellt utformat SQL-kommando visar det att webbplatsen kan attackeras genom SQL-injektion. Denna upptäckt gör det möjligt för utvecklare att åtgärda sårbarheten innan applikationen går i produktion.

Relaterade termer

Ready to validate what matters?

Ready to validate what matters?

Plexicus is Proof-Driven AppSec: validated findings, contextual understanding, and reviewed remediation — anchored in evidence, scoped with you.

Qualification

Check whether AI Swarm Pentest fits your environment.

Share the minimum context. We will review the scope and tell you the next commercial step.

Before submitting — verify you fit

Teams with fewer than 50 developers: start a 14-day Trial instead of booking a demo. Start a 14-day Trial →

0 / 280

No commitment. If you don't fit, we'll tell you.

SAMPLE HANDOVER · ILLUSTRATIVE

Sample evidence handover

A trimmed view of what your team receives at the end of an AI Swarm Pentest engagement. Real engagements include full technical evidence, executive narrative, and a remediation plan.

VALIDATED FINDING Evidence attached

Server-Side Request Forgery in webhooks/receiver

demo-project/sample-app · src/webhooks/receiver.py:42

SeverityHigh CVSS 3.18.6 Priority79 Confirmedvia replay

Untrusted caller-supplied URLs reach an internal egress without an allowlist. Replayed in a sandbox against a fresh authorised target — the same control was validated to fail twice.

REVIEWER-READY REMEDIATION Merge-ready PR

Validate the target URL against an allowlist of permitted hostnames. Reject private/internal IP ranges. Enforce HTTPS only.

plexicus/remediation/webhooks-ssrf 3 changed · 0 new files
42resp = requests.get(target_url)
42+if not is_allowed_host(target_url):
43+  raise WebhookRejected(target_url)
44+resp = requests.get(target_url, timeout=5)
Every engagement hands over:
  • Executive briefing
  • Validated findings list
  • Merge-ready PRs
  • Compliance mapping (NIS2 · DORA · CRA)