Remove Server header from HTTP responses
Remove the Server header from HTTP responses using HttpContext.Current.Response.Headers.Remove("Server") to prevent server information disclosure.
OWASP Cheat Sheets · all subjects
authentication
408 notes in this subject, read out of this brain and free to use. This is page 3 of 7.
ValidateAntiforgeryToken for GET requests in ASP.NET Core
Apply [ValidateAntiforgeryToken] to GET, HEAD, OPTIONS, or TRACE methods if you need to validate CSRF tokens on these HTTP methods.
X-Frame-Options DENY header for clickjacking protection
Set X-Frame-Options header to DENY to prevent clickjacking attacks by preventing the page from being displayed in a frame.
ECDH key management considerations
When using ECDH encryption: manage nonce as separate data item alongside ciphertext, store private keys securely, validate public keys before use, and implement verification of authenticity between sides.
ECDH for asymmetric encryption and key exchange
Use Elliptic Curve Diffie-Hellman (ECDH) together with AES-GCM to perform encryption between two sides without transferring the symmetric key. Sides exchange public keys and use ECDH to generate a shared secret for symmetric encryption.
Application Insights for .NET monitoring
Use Application Insights as a monitoring tool to add monitoring capabilities to .NET applications and validate performance and health through key performance indicators.
Uri.IsWellFormedUriString for URI validation
Validate the format of URIs using Uri.IsWellFormedUriString method before using user-provided URLs.
ValidateRequest enabled by default for XSS protection
Do not disable validateRequest in web.config as it provides limited but valuable XSS protection in ASP.NET. Leave this setting intact for partial prevention of Cross Site Scripting.
Entity Framework SQL injection prevention
Using Entity Framework is a very effective SQL injection prevention mechanism. However, building ad hoc queries in Entity Framework is just as susceptible to SQL injection as plain SQL queries. Always use parameterized queries.
Do not rely on sanitization of special characters
Do not assume you can sanitize special characters without actually removing them. Various combinations of backslash, single quote, and @ may have unexpected impact on sanitization attempts and bypass it.
Accept only alphanumeric characters when possible
Try to only accept characters which are simple alphanumeric in user input to reduce the attack surface.
Input validation allowlist preference
Use allowlist validation on all user supplied input wherever possible. Allowlists are always safer than denylists for input validation.
Do not roll your own authentication or session management
Do not implement custom authentication or session management. Use the frameworks provided by .NET such as ASP.NET Core Identity or ASP.NET Membership.
Insecure direct object reference prevention - authorization check
When accessing resources by reference (e.g., by ID), verify the user is authorized to access that specific resource. Check that user.Id == _userIdentity.GetUserId() before allowing access.
HTTP POST with TLS for RESTful services
Use HTTP POST with TLS enabled for RESTful services. HTTP GET requires data in the URL (query string) which is visible, logged, and stored in browser history.
TransportWithMessageCredential for WCF dual security
Use TransportWithMessageCredential security mode for WCF bindings to combine message security (headers) with transport security (SSL).
WSHttpBinding for WCF security
In WCF services, use WSHttpBinding instead of BasicHttpBinding. BasicHttpBinding has no default security configuration, while WSHttpBinding provides built-in security.
HSTS preload registration
Register your application at hstspreload.org to protect users from MITM attacks on first visit before HSTS header is seen.
HSTS header configuration for HTTP to HTTPS
Set HSTS (Strict-Transport-Security) header with value "max-age=15768000" to protect against MITM attacks. This can be configured in IIS or via web.config rewrite rules.
Url.IsLocalUrl for redirect validation
Use Url.IsLocalUrl(returnUrl) to validate return URLs before redirecting, ensuring redirects only go to local URLs. Use it in a RedirectToLocal helper method.
ASP.NET Membership provider password storage
ASP.NET Membership provider uses SHA-1 with single iteration which is weak. ASP.NET Identity uses PBKDF2 by default which is better. Review Password Storage Cheat Sheet for current best practices.
Forms authentication timeout and sliding expiration
Reduce Forms Authentication timeout from the default 20 minutes to the shortest appropriate period. With slidingExpiration enabled, active users won't be logged out. Without HTTPS, slidingExpiration should be disabled.
Avoid AllowHTML attribute and Html.Raw helper
Do not use the [AllowHTML] attribute or @Html.Raw helper unless absolutely sure the content is safe and has been properly escaped.
AntiXssEncoder library for comprehensive input encoding
Use the AntiXssEncoder library (System.Web.Security.AntiXss.AntiXssEncoder) available in .NET Framework 4.5+ for comprehensive input encoding to prevent XSS across HTML, JavaScript, CSS, LDAP, etc.
Double-submit cookie CSRF protection in Web Forms
If not using ViewState in ASP.NET Web Forms, implement manual anti-CSRF token using double-submit cookie pattern with AntiXsrfToken and AntiXsrfUserName keys, setting HttpOnly=true and Secure=true when HTTPS is used.
ViewStateUserKey for Web Forms CSRF protection
In ASP.NET Web Forms, set ViewStateUserKey = Session.SessionID in Page_Init to provide CSRF mitigation with ViewState.
Always Encrypted for sensitive SQL Server data
Use Always Encrypted for sensitive data in SQL Server 2016+ and Azure SQL to encrypt data at the application level.
Integrated authentication vs SQL authentication for SQL Server
Prefer integrated authentication over SQL authentication when connecting to SQL Server.
Allowlist validation for enum values using Enum.IsDefined
Use Enum.IsDefined to validate whether an input value is valid within the list of defined enum constants. .NET only validates a successful cast to the underlying data type, so additional validation is needed.
Do not write your own cryptographic functions
Never write your own cryptographic functions. Use pre-existing secrets management solutions or libraries specifically designed for cryptography.
Parameterized SQL commands for all data access
Use Parameterized SQL commands for all data access without exception. Never concatenate SQL strings with user input.
Web.config encryption using aspnet_regiis for legacy applications
For legacy .NET Framework applications that cannot be modified, encrypt sensitive web.config sections using aspnet_regiis -pe command. Note this only protects the file at rest on the server; the application loads plaintext into memory.
Configuration Builders for secret injection in .NET Framework
For .NET Framework 4.7.1+, use Configuration Builders (e.g., Microsoft.Configuration.ConfigurationBuilders.Azure, ...Environment) to inject secrets at runtime from secret stores or environment variables so they never appear in web.config.
Do not trust relational data in URIs
Do not trust the URI of the request for persistence of session or authorization data. URIs can be easily faked by users.
Secrets management - do not store in config files
Do not store secrets in source-controlled config files (web.config, appsettings.json). Use User Secrets for development and managed secret stores (Azure Key Vault, AWS Secrets Manager, HashiCorp Vault) accessed via Managed Identity for production.
IPAddress.TryParse and Uri.CheckHostName for SSRF validation
Use IPAddress.TryParse() to validate IP addresses and Uri.CheckHostName() to validate domain names before using them in requests to prevent SSRF attacks.
SSRF prevention - allowlist protocols and domains
Use an allowlist of allowed protocols and domains for SSRF prevention. Validate and sanitize all user input before using it to make requests.
Cookieless authentication and UseDeviceProfile
If using cookieless authentication, it will default to UseDeviceProfile mode. Prefer using cookies for session persistence when possible.
EnableVersionHeader false to hide .NET version
Set httpRuntime enableVersionHeader="false" in web.config system.web section or via Machine.config to prevent .NET version disclosure in HTTP headers.
actions/checkout persist-credentials: false setting
Unless needed for git operations, 'actions/checkout' should be used with 'persist-credentials: false'. This prevents Git credentials from being persisted to the workflow's environment, reducing the risk of credential exposure if the workflow is compromised.
Secure handling of unavoidable static credentials in workflows
If complete elimination of static credentials cannot be achieved: (1) Never hardcode secrets in workflow files; (2) Pass secrets at the step level, not the job level; (3) Prefer environment-level secrets that are only accessible when a job targets a specific environment; (4) Rotate secrets regularly.
Enforce branch protection and repository rulesets
Enforce strong branch protection rules configured to require pull request reviews, status checks, signed commits and CODEOWNERS approval before merging into protected branches. Require workflows to pass before merging via repository rulesets to enforce organizational or enterprise-level requirements such as checking for required labels or validating commit messages before code is merged. Tools such as OpenSSF Scorecard can help audit these settings.
GITHUB_TOKEN default permissions setting
Restrict default GITHUB_TOKEN permissions to 'Read repository contents and packages permissions' in the repository settings. Explicitly grant additional permissions in the workflow file only if required.
Mask sensitive data in GitHub Actions logs
Mask all sensitive information that is not a GitHub secret by using '::add-mask::{value}'. Masking a value prevents a string or variable from being printed in the log.
Eliminate secrets: inherit when reusing workflows
When using the 'inherit' keyword while invoking a reusable workflow, all the calling workflow's secrets (organization, repository and environment secrets) are passed to the called workflow, even if not needed. When calling a reusable workflow, explicitly pass each secret required by the called workflow.
GitHub environments for deployment approval
Use GitHub environments with required approval rules to require manual approval for deployments or publications to critical environments. Define a list of authorized accounts who must manually approve deployments to production or other critical environments before workflow execution.
Eliminate static credentials via OIDC-based authentication
Eliminate all static credentials from workflows (personal access tokens, static cloud keys). Migrate to OIDC-based short-lived authentication tokens (Trusted publishing). Many major registries and cloud providers currently support this feature.
Workflow-level permissions default setting
Always set 'permissions: {}' at the workflow level to disable all permissions by default. Then grant only the specific permissions needed at the job level.
Require approval for all external contributors setting
Enable the setting 'Require approval for all external contributors' in the repository settings to ensure that workflows triggered by pull requests from forks do not run automatically, preventing untrusted code execution. Do not use 'Require approval for first-time contributors' because an attacker can submit an initially legitimate-looking pull request to gain trust and later submit malicious changes executed without further approval.
Secret scanning in pre-commit and pull request stages
Implement secret scanning in both pre-commit and pull request stages to prevent accidental exposure of sensitive data: (1) Run secret scanning locally (e.g., via pre-commit hooks) to catch issues before code is committed; (2) Enforce scanning in pull requests to detect and block any leaked secrets before merging; (3) Automatically fail checks when potential secrets are detected to ensure remediation before proceeding.
GraphQL introspection disable implementation: JavaScript
In JavaScript, disable GraphQL introspection by adding NoIntrospection to the validationRules when using graphqlHTTP middleware: app.use('/graphql', graphqlHTTP({schema: MySessionAwareGraphQLSchema, validationRules: [NoIntrospection], graphiql: process.env.NODE_ENV === 'development',}))
GraphQL introspection disable implementation: Java
In Java, disable GraphQL introspection by setting the field visibility when building the GraphQLSchema: GraphQLSchema.newSchema().query(StarWarsSchema.queryType).fieldVisibility(NoIntrospectionGraphqlFieldVisibility.NO_INTROSPECTION_FIELD_VISIBILITY).build()
GraphQL: disable GraphiQL in production
Disable GraphiQL and other similar schema exploration tools in production or publicly accessible environments.
GraphQL: disable introspection in production
Disable or restrict introspection queries system-wide in any production or publicly accessible environments. Although security by obscurity is not recommended, disabling introspection can prevent leaking information about API schemas, mutations, and deprecated fields. For internal APIs, the easiest approach is to just disable introspection system-wide. If your implementation does not natively support disabling introspection or if you would like to allow some consumers or roles to have this access, build a filter in your service to only allow approved consumers to access the introspection system.
GraphQL access control: use Resolvers for validation
Query and Mutation Resolvers can be used to perform access control validation, possibly using some RBAC middleware.
GraphQL access control: use Interfaces and Unions for permissions
Use GraphQL Interfaces and Unions to create structured, hierarchical data types which can be used to return more or fewer object properties according to requester permissions.
GraphQL access control: check both edges and nodes
Enforce authorization checks on both edges and nodes in GraphQL queries. A security bug occurs when nodes do not have authorization checks but edges do, or vice versa, allowing unauthorized access.
GraphQL access control: authorization validation
Always validate that the requester is authorized to view or mutate or modify the data they are requesting. This can be done with RBAC or other access control mechanisms. This will prevent IDOR issues, including both BOLA (broken object-level authorization) and BFLA (broken function-level authorization).
GraphQL: prevent field name guessing hints
GraphQL has a built-in feature to return a hint when a field name that the requester provides is similar but incorrect to an existing field (e.g., request has 'usr' and the response will ask 'Did you mean "user?"'). Consider disabling this feature if you have disabled introspection to decrease exposure. Not all implementations of GraphQL support disabling this feature. Shapeshifter is one tool that should be able to do this.
GraphQL node/nodes fields IDOR risk
In GraphQL it is possible to have 'node' or 'nodes' fields in a query object that can be used to access objects directly by ID, even if that functionality is not intended. This can lead to broken object-level authorization (IDOR). Removing these fields from the schema should disable the functionality, but always apply proper authorization checks to verify the caller has access to the object they are requesting. Check if your schema has these fields by running: cat schema.json | jq ".data.__schema.types[] | select(.name==\"Query\") | .fields[] | .name" | grep node