Rileva server-side request forgery (SSRF) prima del merge.

Scopri come server-side request forgery (SSRF) entra in una revisione local-first, quali evidenze produce Code Radar, dove finisce la copertura e come portare finding affidabili in CI.

Controlla questo rischio in locale Rivedi le prove di rilevamento

radar scan . --quick

Cosa significa server-side request forgery (SSRF) qui.

La regola server-side request forgery (SSRF) individua pattern che possono creare rischio sfruttabile o nascondere debito rilevante e restituisce posizione, severità, confidenza e rimedi.

Riferimento regola

Prova da ispezionare

Usa «Rileva server-side request forgery (SSRF) prima del merge.» come ambito della decisione: verifica input, dettaglio dei finding, passaggio del workflow e confini del prodotto prima di installare o acquistare.

CriterioProva da ispezionareConfine

Ambito di inputFile selezionati, configurazione, modalità e regole attive.Sono valutati solo percorsi e controlli inclusi.

Dettaglio findingFile, riga, ID regola, gravità, spiegazione e riparazione.L'output illustrativo non è un risultato del tuo repository.

Passaggio del workflowRisultato locale, report, contesto agente e segnale CI opzionale.Abilita export o CI solo quando servono al workflow.

Fit decisionaleApplica gli stessi criteri a un repository reale prima di scegliere.Non viene dichiarato un vincitore universale né un risultato garantito.

Riferimento regola

Controlla questo rischio in locale

Copertura e segnali concreti

Per server-side request forgery (SSRF), controlla l'ambito concreto sotto invece di affidarti a una sola categoria. Focus: sicurezza del codice sorgente; RADAR-SEC-SSRF, sicurezza del codice sorgente.

Pubblico: sviluppatori che devono capire questo rischio prima del merge: server-side request forgery (SSRF).
Evidenze da controllare prima di fidarsi del risultato.: File esatto, contesto regola, severità, confidenza e indicazioni di rimedio. RADAR-SEC-SSRF, sicurezza del codice sorgente. Output terminale e artefatti SARIF, JSON o HTML generati dallo stesso insieme di finding.
Confine: Il rilevamento statico è evidenza, non prova di sfruttabilità. Controlla flusso dati e contesto, documenta i falsi positivi e testa il comportamento corretto.
ID regola: RADAR-SEC-SSRF

Pattern rischioso / Pattern più sicuro

server-side request forgery (SSRF): Un risultato utile deve essere spiegabile a uno sviluppatore e trasferibile al passaggio successivo. Controlla queste evidenze prima di cambiare la policy del team.

Pattern rischiosoPattern più sicuro

fetch(request.query.url);fetch(allowlistedServiceUrl(request.query.service));

Dal segnale locale al gate condiviso.

server-side request forgery (SSRF): Usa il flusso minimo che dimostra valore. Ogni passaggio successivo deve riutilizzare evidenze che il team già comprende. File esatto, contesto regola, severità, confidenza e indicazioni di rimedio. RADAR-SEC-SSRF, sicurezza del codice sorgente. Output terminale e artefatti SARIF, JSON o HTML generati dallo stesso insieme di finding.

PassoComando o azioneDecisione

1Eseguire una scansione locale rapidaIl segnale è utile?

2Controllare e correggere i findingLa correzione è specifica e riproducibile?

3Esportare evidenze portabiliIl reviewer richiede SARIF, JSON o HTML?

4Portare la soglia affidabile in CIQuale severità deve bloccare una pull request?

radar scan . --quick
radar scan . --format sarif --fail-on high

Fonte ufficiale

Fonti primarie

Valida il workflow sul tuo codice.

Applica le prove di questa pagina a un repository reale. Per «Rileva server-side request forgery (SSRF) prima del merge.», conferma quale finding viene prodotto, se il passo successivo è riproducibile e dove scansione locale, report, agenti o CI devono fermarsi o ampliarsi.