Code RadarLOCAL SAST GATE
KontoGitHubRadar installieren

SQL-Injection vor dem Merge erkennen.

Erfahren Sie, wie SQL-Injection in ein lokales Code-Review passt, welche Nachweise Code Radar erzeugt, wo die Abdeckung endet und wie vertrauenswürdige Findings in CI gelangen.

Dieses Risiko lokal prüfenErkennungsnachweis prüfen
radar scan . --quick

Was SQL-Injection hier bedeutet.

Die Regel SQL-Injection erkennt Muster, die ausnutzbares Verhalten erzeugen oder wesentliche Wartungsrisiken verbergen können, und liefert Ort, Schweregrad, Konfidenz und Behebung.

Regelreferenz

Zu prüfender Nachweis

Prüfe Eingabeumfang, Finding-Details, Workflow-Übergabe und Produktgrenzen vor Installation oder Kauf.

KriteriumZu prüfender NachweisGrenze
EingabeumfangAusgewählte Dateien, Konfiguration, Scanmodus und aktive Regeln.Nur einbezogene Pfade und Checks werden bewertet.
Finding-DetailsDatei, Zeile, Regel-ID, Schweregrad, Erklärung und Reparaturweg.Illustrative Ausgabe ist kein Ergebnis deines Repositorys.
Workflow-ÜbergabeLokales Ergebnis, Bericht, Agent-Kontext und optionales CI-Signal.Exporte oder CI nur bei tatsächlichem Workflow-Bedarf aktivieren.
EntscheidungsfitDieselben Kriterien vor der Wahl in einem echten Repository anwenden.Kein universeller Gewinner oder garantiertes Ergebnis.
Regelreferenz

Dieses Risiko lokal prüfen

Prüfe Eingabeumfang, Finding-Details, Workflow-Übergabe und Produktgrenzen vor Installation oder Kauf.

Dieses Risiko lokal prüfen

Das Problem, das diese Seite klärt

Die wichtige Frage ist, wo SQL-Injection den Review-Ablauf verändert: was geprüft wird, wer auf ein Finding reagiert und welche Nachweise weitergehen. Bei SQL-Injection zählt der konkrete Umfang unten, nicht nur ein Kategoriename. Fokus: Quellsicherheit; RADAR-SEC-SQLI, unsafe pattern, safer pattern, Quellsicherheit.

  • Zielgruppe: Entwickler, die dieses Risiko vor dem Merge verstehen müssen: SQL-Injection.
  • Fokus: Bei SQL-Injection zählt der konkrete Umfang unten, nicht nur ein Kategoriename. Fokus: Quellsicherheit; RADAR-SEC-SQLI, unsafe pattern, safer pattern, Quellsicherheit.
  • Prüffrage: Was deckt SQL-Injection praktisch ab?

Abdeckung und konkrete Signale

Bei SQL-Injection zählt der konkrete Umfang unten, nicht nur ein Kategoriename. Exakte Datei, Regelkontext, Schweregrad, Konfidenz und Hinweise zur Behebung. RADAR-SEC-SQLI, unsafe pattern, safer pattern, Quellsicherheit. Terminalausgabe sowie SARIF-, JSON- oder HTML-Artefakte aus demselben Finding-Satz.

  • Fokus: Bei SQL-Injection zählt der konkrete Umfang unten, nicht nur ein Kategoriename. Fokus: Quellsicherheit; RADAR-SEC-SQLI, unsafe pattern, safer pattern, Quellsicherheit.
  • Workflow: Regel-ID: RADAR-SEC-SQLI
  • Abdeckung und konkrete Signale: RADAR-SEC-SQLI, unsafe pattern, safer pattern, Quellsicherheit
FokusExakte Datei, Regelkontext, Schweregrad, Konfidenz und Hinweise zur Behebung.Grenze
Bei SQL-Injection zählt der konkrete Umfang unten, nicht nur ein Kategoriename. Fokus: Quellsicherheit; RADAR-SEC-SQLI, unsafe pattern, safer pattern, Quellsicherheit.Exakte Datei, Regelkontext, Schweregrad, Konfidenz und Hinweise zur Behebung. RADAR-SEC-SQLI, unsafe pattern, safer pattern, Quellsicherheit. Terminalausgabe sowie SARIF-, JSON- oder HTML-Artefakte aus demselben Finding-Satz.Statische Erkennung ist ein Nachweis, kein Beweis der Ausnutzbarkeit. Prüfen Sie Datenfluss und Kontext, dokumentieren Sie False Positives und testen Sie die Behebung.

Riskantes Muster / Sichereres Muster

SQL-Injection: Ein nützliches Ergebnis muss für Entwickler erklärbar und in den nächsten Review-Schritt übertragbar sein. Prüfen Sie diese Nachweise vor einer Richtlinienänderung.

Riskantes MusterSichereres Muster
db.query(`SELECT * FROM users WHERE id = ${id}`);db.query("SELECT * FROM users WHERE id = ?", [id]);

Vom lokalen Signal zum gemeinsamen Gate.

SQL-Injection: Nutzen Sie den kleinsten Ablauf, der Wert belegt. Jeder spätere Schritt sollte bereits verstandene Nachweise wiederverwenden. Bei SQL-Injection zählt der konkrete Umfang unten, nicht nur ein Kategoriename. Fokus: Quellsicherheit; RADAR-SEC-SQLI, unsafe pattern, safer pattern, Quellsicherheit.

SchrittBefehl oder AktionEntscheidung
1Schnellen lokalen Scan ausführenIst das Signal nützlich?
2Findings prüfen und behebenIst die Behebung konkret und reproduzierbar?
3Portable Nachweise exportierenBraucht das Review SARIF, JSON oder HTML?
4Vertrauenswürdige Schwelle in CI übernehmenWelcher Schweregrad soll einen Pull Request blockieren?
radar scan . --quick
radar scan . --format sarif --fail-on high

Nachweise, die vor Vertrauen geprüft werden sollten.

SQL-Injection: Ein nützliches Ergebnis muss für Entwickler erklärbar und in den nächsten Review-Schritt übertragbar sein. Prüfen Sie diese Nachweise vor einer Richtlinienänderung. Exakte Datei, Regelkontext, Schweregrad, Konfidenz und Hinweise zur Behebung. RADAR-SEC-SQLI, unsafe pattern, safer pattern, Quellsicherheit. Terminalausgabe sowie SARIF-, JSON- oder HTML-Artefakte aus demselben Finding-Satz.

  • Regel-ID: RADAR-SEC-SQLI
  • Exakte Datei, Regelkontext, Schweregrad, Konfidenz und Hinweise zur Behebung.
  • Terminalausgabe sowie SARIF-, JSON- oder HTML-Artefakte aus demselben Finding-Satz.
  • Der Quellcode bleibt im Workspace oder CI-Runner, in dem der Scan ausgeführt wird.

Passung und Grenzen

Nutze SQL-Injection, wenn Entwickler, die dieses Risiko vor dem Merge verstehen müssen: SQL-Injection. Halte die Grenze klar: Statische Erkennung ist ein Nachweis, kein Beweis der Ausnutzbarkeit. Prüfen Sie Datenfluss und Kontext, dokumentieren Sie False Positives und testen Sie die Behebung.

Den lokalen Nachweis ausführen, bevor ein gemeinsames Gate eingeführt wird.

  • Gute Passung: Entwickler, die dieses Risiko vor dem Merge verstehen müssen: SQL-Injection.
  • Nicht passend / nicht überdehnen: Statische Erkennung ist ein Nachweis, kein Beweis der Ausnutzbarkeit. Prüfen Sie Datenfluss und Kontext, dokumentieren Sie False Positives und testen Sie die Behebung.

Fragen vor dem Rollout prüfen

Diese Fragen binden die Entscheidung an beobachtbare Nachweise statt an ein pauschales Versprechen.

Was deckt SQL-Injection praktisch ab?

SQL-Injection: Der praktische Umfang ist Bei SQL-Injection zählt der konkrete Umfang unten, nicht nur ein Kategoriename. Fokus: Quellsicherheit; RADAR-SEC-SQLI, unsafe pattern, safer pattern, Quellsicherheit.. Starte mit den genannten Entitäten oder Dateien und prüfe das Ergebnis an repräsentativem Code.

Welche Nachweise sollte ich für SQL-Injection prüfen?

SQL-Injection: Prüfe Exakte Datei, Regelkontext, Schweregrad, Konfidenz und Hinweise zur Behebung. RADAR-SEC-SQLI, unsafe pattern, safer pattern, Quellsicherheit. Terminalausgabe sowie SARIF-, JSON- oder HTML-Artefakte aus demselben Finding-Satz. und halte Fundstelle, Regel- oder Vergleichskontext und Exportartefakt zusammen.

Was sollte ich aus SQL-Injection nicht ableiten?

SQL-Injection: Leite keine universelle Abdeckung ab. Statische Erkennung ist ein Nachweis, kein Beweis der Ausnutzbarkeit. Prüfen Sie Datenfluss und Kontext, dokumentieren Sie False Positives und testen Sie die Behebung. Prüfe die Grenze auf der passenden Vergleichs- oder Workflow-Seite, bevor du die Policy änderst.

Was sollte ich für SQL-Injection zuerst testen?

SQL-Injection: Starte lokal, prüfe ein echtes Finding und öffne danach den passenden Bericht-, Agent-, CI- oder Vertrauens-Workflow.

Funktion: security scannerWähle die Seite, die den offenen Implementierungs- oder Bewertungsschritt abschließt.Funktion: sastWähle die Seite, die den offenen Implementierungs- oder Bewertungsschritt abschließt.Docs: rulesWähle die Seite, die den offenen Implementierungs- oder Bewertungsschritt abschließt.
Regelreferenz

Beginnen Sie mit dem Problem, das Sie lösen müssen.

Seite öffnen →
Local SASTLokales SAST für Entwickler und CI

Code Radar erzeugt portable Evidenz in Terminal, SARIF, JSON und HTML, damit Menschen, CI, Automatisierung und Agenten mit demselben Finding-Set arbeiten.

NachweisBeispielbericht ansehen

the fields and Formate in a sample Befund inspizieren

InstallierenRadar installieren

a lokaler Scan on a echtes Repository ausführen

Den Workflow am eigenen Code validieren.

Mit einem lokalen Scan beginnen, Nachweise prüfen und erst bei nützlichem Signal auf Berichte, Agents oder CI erweitern.

Dieses Risiko lokal prüfenErkennungsnachweis prüfen