DepWarden's free C# SAST scanner checks C# source code against 34 security rules (including 7 ASP.NET Core-specific rules). Every rule maps to a CWE and the findings span 7 OWASP Top 10 categories, and every finding comes with an explanation, a fix and a before-and-after example. Paste a file, upload a zip or connect a repository: no account, and the results stay in a private, session-isolated workspace.
C# runs ASP.NET Core web applications and services on .NET. The recurring issues are SQL built with string interpolation, unsafe deserialization, weak cryptography and insecure cookie or CORS configuration.
34 rules cover 22 distinct weakness types (7 critical, 18 high, 6 medium and 3 low severity).
| What it checks | Rules | Examples |
|---|---|---|
| Weak cryptography | 15 | MD5 used for password hashing; Null or no-op cipher used; TLS certificate validation disabled — trust all certs |
| Injection (SQL, command, code) | 4 | LDAP injection via DirectorySearcher; OS command injection; SQL injection via concatenation |
| Cross-site scripting | 3 | Reflected XSS via Response.Write; ASP.NET request validation disabled globally; ASP.NET ValidateInput disabled |
| Insecure configuration | 3 | ASP.NET Core CORS credentials + wildcard origin; ASP.NET Core HTTPS metadata disabled; ASP.NET Core CORS allows any origin |
| Hardcoded secrets | 2 | ASP.NET machineKey hardcoded in config; Hardcoded symmetric encryption key |
| Access control | 1 | Open redirect via Response.Redirect |
| Authentication and sessions | 1 | ASP.NET Core [AllowAnonymous] on potentially sensitive controller |
| Insecure deserialization | 1 | Insecure deserialization |
| Path traversal | 1 | Path traversal in file operations |
| Privacy and data leaks | 1 | Console.WriteLine in production service code |
| Reliability and error handling | 1 | Empty catch block in C# |
| Server-side request forgery | 1 | SSRF via HttpClient with user-supplied URL |
A hardcoded machineKey allows an attacker who reads the config to forge authentication cookies and ViewState payloads, leading to authentication bypass or RCE.
Vulnerable:
<machineKey validationKey="0123456789ABCDEF0123456789ABCDEF" decryptionKey="..." />Fixed:
<!-- Remove the explicit machineKey and let IIS/ASP.NET auto-generate + manage it, or load from Azure Key Vault -->Remove machineKey from web.config and use DPAPI or Azure Key Vault to manage keys.
BinaryFormatter / SoapFormatter / LosFormatter deserialization enables RCE on untrusted data.
Vulnerable:
var formatter = new BinaryFormatter();
var obj = formatter.Deserialize(untrustedStream);Fixed:
var obj = JsonSerializer.Deserialize<MyType>(untrustedStream);Avoid BinaryFormatter; use System.Text.Json with a fixed type.
Combining AllowCredentials() with AllowAnyOrigin() is a security misconfiguration. All browsers block such responses; it also signals an attempt to bypass the same-origin policy.
Vulnerable:
b.AllowAnyOrigin().AllowCredentials();Fixed:
b.WithOrigins("https://example.com").AllowCredentials();Never combine AllowCredentials with AllowAnyOrigin. List explicit origins.
- uses: Rushabh5000/depwarden-action@v1
with:
sast-dir: src
sast-fail-on: high
env:
APP_API_KEY: ${{ secrets.APP_API_KEY }}DepWarden's SAST engine uses pattern rules and taint-aware rules that require untrusted input to reach a dangerous call. It is not a full cross-file dataflow engine, so a bug that only appears when data crosses several files can be missed, and every static analyser reports some false positives. Treat findings as leads: review them, fix the real ones and suppress the rest with a written reason. SAST covers the code you write; for the packages you import, run software composition analysis too.
Yes. DepWarden's C# scanner is free in the browser with no account: paste code, upload a zip or connect a repository. Running SAST from CI through an API key needs a plan that includes SAST.
.cs. Configuration and secret-bearing files such as .env and key files are also checked for hardcoded credentials, whatever language the project uses.
Each finding names the weakness (CWE), explains why the code is risky, shows a vulnerable and a fixed version of the pattern, and gives the remediation. Fix the code, then scan again to confirm the finding is gone.
Other languages: Python, Java, JavaScript and TypeScript, PHP, Go (Golang), Ruby, Kotlin, Swift, and secret scanning. Compare the options in free SAST tools compared, or start with what is SAST and SAST vs SCA.