In this article we’re going to go through some security best practices around the technologies that I’ve used over the years I’ve been working as a software developer. I’m going delve into multiple security topics related to different technology, but I’ll try to keep it in checklist format and short for it to be easier to skim through.

ASP.NET Core Security Best Practices

HTTPS Everywhere:

Always use HTTPS for your applications.
Configure your app to redirect HTTP traffic to HTTPS using the UseHttpsRedirection middleware.

Data Protection:

ASP.NET Core provides a data protection API that can be used to encrypt data, especially for things like authentication tokens and state data.
Make sure the Data Protection API is properly configured and you are aware of where and how the encryption keys are stored.

Keep Dependencies Updated:

Regularly check for updates to ASP.NET Core and its packages. Updated versions may contain important security patches.

Input Validation:

Always validate input on the server side, even if it’s validated on the client side. Use built-in model validation provided by ASP.NET Core.
Be wary of using user input directly in SQL queries or other interpreters; this exposes you to injection attacks.

Authentication & Authorization:

Use built-in mechanisms like ASP.NET Core Identity for user management, authentication, and authorization.
Ensure roles and policies are well-defined and strictly control access to resources.

Use Cross-Origin Resource Sharing (CORS) Wisely:

If you need to allow cross-domain requests, be specific about which domains can access your API and limit exposed methods.

CSRF Protection:

Use the built-in Anti-Forgery Token feature in ASP.NET Core to protect against Cross-Site Request Forgery attacks.

Content Security Policy (CSP):

Implement a strict CSP to prevent Cross-Site Scripting (XSS) attacks. This helps you ensure that only safe sources of content are executed in the browser.

Error Handling:

Use the UseExceptionHandler middleware to handle exceptions gracefully. Avoid showing detailed error messages to the end users, as this could expose sensitive information or details about your application’s structure.

Database Security:

Use parameterized queries or Object-Relational Mapping (ORM) like Entity Framework Core to prevent SQL injection attacks.
Limit the permissions of the database user connected by the application to only what’s necessary.

Logging & Monitoring:

Monitor and log activities and errors. Be sure not to log sensitive information.
Use libraries like Serilog or NLog for structured logging.

Header Security:

Consider removing or customizing HTTP headers that leak information about your server or framework, like Server or X-Powered-By.
Implement security headers like X-Content-Type-Options, X-Frame-Options, and Strict-Transport-Security.

Limit Exposed Data:

Always follow the principle of least privilege. Only send to the client or expose APIs that provide the minimal necessary data.

Session Management:

Use secure, random session identifiers.
Implement session expiration and remember to secure session data.

Protect APIs:

If exposing APIs, consider using OAuth2 or JWT for securing them.

Regular Security Audits:

Periodically review your application for vulnerabilities. Tools like OWASP ZAP can assist in identifying potential threats.

Use Strong Password Policies: Enforce strong password policies for your users. This includes minimum lengths, complexity requirements, and regular password changes.

Use Secure Cookies: Use secure cookies to prevent them from being sent over unencrypted connections. Also, consider using HttpOnly cookies to prevent them from being accessed by client-side scripts.

Implement Rate Limiting: This can help protect your application against brute-force attacks or DDoS attacks.

Limit Exposure of Sensitive Information: Avoid exposing sensitive information in error messages or logs. Use ASP.NET Core’s built-in logging providers to filter out sensitive information.

RESTful APIs Security Best Practices

Use HTTPS: Always use HTTPS to ensure that the data transferred between the client and server is encrypted and secure.

Authentication:

Use standard authentication methods like JWT (JSON Web Tokens) or OAuth.
Avoid sending sensitive data like passwords in the URL.

Authorization:

Always check if the authenticated user has the right permissions to perform an action or access resources.
Implement role-based or claim-based authorization, as needed.

Input Validation:

Always validate data coming from the client to ensure it’s the correct type, length, format, and range.
Use model validation in ASP.NET Core or ASP.NET MVC.
Avoid trusting user input. This helps protect against SQL injection, cross-site scripting (XSS), and other attacks.

Cross-Origin Resource Sharing (CORS):

Cross-Origin Resource Sharing (CORS) is a security feature that can prevent your API from being accessed from unauthorized domains. Make sure to configure it properly.
Configure CORS properly if your API needs to be accessed by web applications from different domains.
Use the CORS middleware in ASP.NET Core to define which origins can access the API.

Protect against Cross-Site Request Forgery (CSRF):

Though CSRF is more relevant for traditional web apps, if your API also serves HTML views or is used in a mixed scenario with web views, use anti-forgery tokens to protect against CSRF attacks.

Content Security Policy (CSP): If you serve HTML from your API, implement a strict Content Security Policy to mitigate XSS risks.

API Rate Limiting:

Use middleware like AspNetCoreRateLimit to implement rate limiting on your API. This prevents abuse and protects your API from denial-of-service attacks.

Secure your Dependencies:

Regularly update your packages to the latest versions to get security patches.
Check for vulnerabilities in your dependencies using tools like dotnet-outdated or NuGet Package Explorer.

Logging and Monitoring:

Implement logging to monitor for any suspicious activities.
Avoid logging sensitive data. Use log sanitizers if necessary.

Database Security:

Always use parameterized queries or ORM (like Entity Framework) to protect against SQL injection.
Limit database permissions. Use the principle of least privilege.

Headers:

Consider adding security headers like X-Content-Type-Options, X-Frame-Options, and Strict-Transport-Security.
Remove unnecessary information from response headers (e.g., server version).

Data Protection:

Use the built-in ASP.NET Core Data Protection system for encrypting sensitive data.

Error Handling:

Implement global error handling and ensure that detailed error messages (stack traces, database error details, etc.) are not exposed to the client.

Secure Configuration:

Keep secrets (e.g., API keys, connection strings) out of code and configuration files. Use secure methods like the Secret Manager tool in development and Azure Key Vault in production.

Regular Security Audits:

Use tools like OWASP ZAP or commercial solutions to regularly scan your API for vulnerabilities.

Use Anti-Forgery Tokens for APIs: While this is more relevant for form submissions in web applications, APIs can also be vulnerable to CSRF attacks. If your API is consumed by a browser client, consider using anti-forgery tokens.

Secure Your Cookies: If you use cookies in your API, use secure cookies to prevent them from being sent over unencrypted connections. Also, consider using HttpOnly cookies to prevent them from being accessed by client-side scripts.

React and NPM Security Best Practices

React XSS Protection: By default, React offers protection against XSS attacks. Use JSX data binding with curly braces ({}) to escape values automatically. Do not use dynamic attribute values without validation.
URL Security: URLs can carry malicious scripts, especially with the javascript: protocol. Always validate URLs to ensure they are either http: or https:. Validate with native URL parsing and check against an allow list.
HTML Sanitization: When using dangerouslySetInnerHTML to insert HTML into the DOM, always sanitize the content beforehand with a library like dompurify.
Avoiding Direct DOM Access: Refrain from direct DOM manipulation. If it’s unavoidable, use dangerouslySetInnerHTML with sanitized data. Do not directly inject content using refs or findDomNode().
Server-Side Rendering Security: When using server-side rendering functions, like ReactDOMServer.renderToString(), ensure you don’t concatenate unsanitized data with the output.
Dependencies & Vulnerabilities: Always check for vulnerabilities in your third-party dependencies. Tools like Snyk can be integrated into your development process (e.g., through VS Code extensions or the CLI) to automatically identify and fix security concerns.
JSON Injection Protection: When sending JSON data with server-side rendered pages, replace characters like < to protect against injection attacks.
React Version Updates: To ensure security, always keep React and its related libraries up to date. Use tools like npm outdated to identify older versions.
Linters for Security: Use linter configurations and plugins tailored for security. These tools can auto-detect issues in your code. Ensure to integrate security checks into your commit workflow, potentially with tools like husky.
Caution with Library Code: Be wary of library code that engages in unsafe practices like unsanitized DOM manipulation. Regularly review the libraries you use and scan them with security-focused linters.
Always Escape Data:
- React inherently escapes data to protect from Cross-Site Scripting (XSS) attacks. When you use JSX to render content, React automatically escapes it. This means if you’re rendering user input, it gets automatically sanitized.
- Avoid using dangerouslySetInnerHTML as it bypasses React’s default escaping. If you absolutely have to use it, ensure content is properly sanitized.
Use PropTypes:
- While PropTypes or Typescript that are primarily for type checking, they can indirectly increase security by ensuring that components receive data of expected types.
Protect against CSRF:
- If your React app interacts with a server using cookies, ensure to protect against Cross-Site Request Forgery (CSRF). Use anti-CSRF tokens and ensure your server checks the token with every state-changing request.
Content Security Policy (CSP):
- Implement a strict CSP. This will help in mitigating XSS risks by preventing the execution of unsafe inline scripts.
- When using inline scripts (which is not common in React), generate nonces (cryptographic numbers used once) and configure CSP to accept them.
Dependencies and NPM:
- Regularly update your npm packages. Vulnerabilities in older packages are a common vector for attacks.
- Use tools like npm audit to identify and fix known vulnerabilities in your dependencies.
- Be cautious when installing new npm packages. Ensure they are from reputable sources and have been recently maintained.
Avoid Exposing Sensitive Data:
- Do not store sensitive data in the client-side state of your app. React’s state is easily accessible via browser developer tools.
- If you need to store sensitive data temporarily, consider using JavaScript closures or other mechanisms to keep data out of global scope and away from potential XSS attacks.
Use HTTPS:
- Always serve your React application over HTTPS. This ensures the data exchanged between the server and the client is encrypted.
- If you’re building a Progressive Web App (PWA) with service workers, HTTPS is mandatory.
Hooks and Custom Hooks:
- When creating custom hooks, ensure you’re not introducing side effects that could lead to vulnerabilities. For instance, if a custom hook interacts with an external service, validate and sanitize the data.
- Avoid overexposing state or actions that could be exploited.
Avoid eval():
- Never use JavaScript’s eval() or similar functions that can execute strings as code. This is a common security anti-pattern.
Implement Proper CORS:
- If your React app is talking to an API, ensure the server has proper CORS settings. This prevents unwanted domains from making requests to your API.
- Avoid using the wildcard * in server’s CORS settings for production applications.
Third-party Components:
- Be cautious when using third-party React components (e.g., from npm). They might have vulnerabilities or malicious code.
- Review and vet the code for third-party components, especially if they are not widely recognized or reviewed by the community.
State Management Libraries:
- When using libraries like Redux, ensure that sensitive information is not stored directly in the Redux store, as it can be inspected using browser extensions.
- If you need to persist the store (e.g., with redux-persist), be aware of where the data is being stored (e.g., localStorage) and the potential risks.
Authentication and Authorization:
- Do not solely rely on client-side checks. Always have server-side checks for authentication and authorization.
- Use mature libraries for handling authentication, like Auth0 or Firebase Authentication. They provide best practices out of the box.
Service Workers:
- Be cautious when caching sensitive information in service workers. They can potentially expose data.
Avoid Publishing Secrets to the NPM Registry: Secrets such as API keys and passwords can easily leak into source control or a published package on the public NPM registry. Use .gitignore or .npmignore files to prevent this, and consider using the ‘files’ property in package.json as a whitelist to specify which files should be included in the package.
Secure React Server-Side Rendering: Data binding will provide automatic content escaping when using server-side rendering functions like renderToString() and ReactDOMServer.renderToStaticMarkup(). Avoid concatenating strings onto the output of renderToStaticMarkup() before sending the strings to the client for hydration.
Enforce the Lockfile: Package lockfiles ensure deterministic installations across different environments and enforce dependency expectations across team collaboration. Use ‘yarn install –frozen-lockfile’ or ‘npm ci’ to ensure consistency between package.json and the lockfile.
Minimize Attack Surfaces by Ignoring Run-Scripts: NPM CLI works with package run-scripts, which can be exploited by bad actors to perform malicious acts when their package is installed. To minimize this risk, vet third-party modules, delay upgrading to new versions, review changelogs and release notes before upgrading, and disable the execution of scripts by third-party packages using the ‘–ignore-scripts’ suffix.
Assess NPM Project Health: Use ‘npm outdated’ to see which packages are out of date, and ‘npm doctor’ to review your NPM setup and diagnose any issues.
Use a Local NPM Proxy: If you have specific security, deployment, or performance needs, consider using a local NPM proxy like Verdaccio. This allows you to switch to a different registry and provides several features for managing and scaling your registry.
Responsibly Disclose Security Vulnerabilities: If you find a security vulnerability, follow a responsible disclosure program to ensure that the vulnerability is properly addressed before it is made public.
Enable 2FA (Two-Factor Authentication): Enable 2FA on your NPM account to add an extra layer of security. NPM supports two modes for enabling 2FA: ‘Authorization-only’ and ‘Authorization and write-mode’.
Protect NPM Tokens: NPM tokens authenticate you to the NPM registry and are used for performing registry-related actions during CI and automated procedures. Protect your tokens and minimize their exposure.
Understand Module Naming Conventions and Typosquatting Attacks: Be aware of the rules for naming a module and the risk of typosquatting attacks, where bad actors publish malicious modules with names similar to existing popular modules. Be careful when installing packages and consider using the ‘–ignore-scripts’ option to reduce the risk of arbitrary command execution.

SQL and NoSQL Databases Security Best Practices

SQL Databases (e.g., MySQL, PostgreSQL, SQL Server, Oracle):

SQL Injection Prevention:
- Always use parameterized queries or prepared statements. This means never concatenate or interpolate values directly into your SQL strings.
- Avoid using dynamic SQL unless absolutely necessary. If you must, always validate and sanitize inputs.
- ORM (Object-Relational Mapping) frameworks, like Entity Framework, Hibernate, or Sequelize, inherently protect against SQL injection by using parameterized queries.
Least Privilege Principle:
- Grant only necessary permissions. For example, an application generally doesn’t need the permission to DROP tables.
Use Stored Procedures:
- Encapsulate business logic in stored procedures to reduce the surface area of attack. This can also centralize data validation.
- Using stored procedures can sometimes prevent direct access to tables, requiring users or applications to access data through controlled interfaces.
Regular Backups:
- Always have regular backups in place and ensure that backup data is encrypted and stored securely.
Auditing and Monitoring:
- Enable database audit logs to monitor access and actions. Look out for any unusual patterns or access times.
Encryption:
- Use encryption at rest for the data stored in the database.
- Use encryption in transit using SSL/TLS when data is communicated to and from the database.
Authentication and Authorization:
- Use strong authentication mechanisms and consider using multi-factor authentication for critical database access.
- Avoid using the default root or admin accounts. Create specific accounts with the needed permissions.
Update and Patch:
- Always keep the database software updated to the latest version to ensure security vulnerabilities are patched.
Network Security:
- Restrict database access by IP. Ideally, only application servers and certain IPs should access the database.
- Use firewalls to restrict unnecessary access.
Connecting to the Database: The backend database used by the application should be isolated as much as possible to prevent malicious or undesirable users from connecting to it. This can be achieved by disabling network access, configuring the database to only bind on localhost, restricting access to the network port to specific hosts with firewall rules, or placing the database server in a separate DMZ isolated from the application server.
Transport Layer Protection: Most databases allow unencrypted network connections in their default configurations. To prevent unencrypted traffic, configure the database to only allow encrypted connections, install a trusted digital certificate on the server, and configure the client application to connect using TLSv1.2+ with modern ciphers.
Storing Database Credentials: Database credentials should never be stored in the application source code. Instead, they should be stored in a configuration file that is outside of the webroot, has appropriate permissions, and is not checked into source code repositories.
Database Configuration and Hardening: The underlying operating system for the database server should be hardened based on a secure baseline. The database application should also be properly configured and hardened. This includes installing any required security updates and patches, configuring the database services to run under a low privileged user account, removing any default accounts and databases, storing transaction logs on a separate disk to the main database files, and configuring a regular backup of the database.
Platform and Network Security: The platform for SQL Server includes the physical hardware and networking systems connecting clients to the database servers, and the binary files that are used to process database requests. Best practices for physical security strictly limit access to the physical server and hardware components. Implementing physical network security starts with keeping unauthorized users off the network.

NoSQL Databases (e.g., MongoDB, Cassandra, CouchDB):

Injection Prevention:
- NoSQL databases can also be vulnerable to injection attacks, albeit differently from SQL databases. Always validate and sanitize user input.
- For MongoDB, for instance, be careful with the $where operator or JavaScript functions that might execute arbitrary JavaScript.
Limit Exposure:
- By default, some NoSQL databases, like MongoDB, used to listen to all network interfaces. Always bind your database server to a private IP and use VPNs, VPCs, or internal Docker networks to limit exposure.
Authentication and Authorization:
- Always enable authentication. For example, in MongoDB, use SCRAM (Salted Challenge Response Authentication Mechanism).
- Use role-based access control to limit the capabilities of different users.
Encryption:
- Implement encryption at rest and in transit.
- Some NoSQL databases, like MongoDB, offer field-level encryption, allowing you to encrypt specific sensitive fields in documents.
Backup Regularly:
- Ensure backups are consistent, especially given the distributed nature of some NoSQL systems. Also, ensure backup data is encrypted and stored securely.
Auditing and Monitoring:
- Use built-in auditing tools (if available) to monitor access and changes to data.
Avoid Default Ports:
- Running your NoSQL database on default ports (e.g., 27017 for MongoDB) can make it an easy target. Consider changing to non-default ports.
Regularly Update and Patch:
- Ensure your NoSQL database software is regularly updated to patch any security vulnerabilities.
Validate Data:
- Given the schema-less nature of many NoSQL databases, it’s crucial to validate data both on the client and server-side to prevent malicious data from being saved.
Network Security:

Similar to SQL databases, ensure that network access to your NoSQL database is restricted using firewalls or VPCs.

Generic security related points about databases

Physical Security:
- Limit access to the physical server and hardware.
- Use locked rooms for server hardware and networking devices.
- Store backup media securely offsite.
Operating System Security:
- Apply all service pack and upgrades after testing.
- Utilize firewalls as a security measure.
- Surface area reduction: Disable unused components and run required services with least privileges.
- If using Internet Information Services (IIS), ensure its security.
SQL Server Operating System Files Security:
- Restrict access to system files used by SQL Server.
- Ensure you have the latest service packs and upgrades.
Principals and Database Object Security:
- Principals: Individuals, groups, and processes with access to SQL Server.
- Securables: The server, database, and objects contained.
- Configure permissions to reduce the SQL Server surface area.
Encryption and Certificates:
- Encryption helps limit data loss if access controls are breached.
- Certificates enhance object and connection security.
Application Security:
- Write secure client applications.
- Use Windows Defender Application Control (WDAC) to prevent unauthorized code execution.
SQL Server Security Tools, Utilities, Views, and Functions:
- Tools and utilities are provided for configuring and administering security.
- Database Engine offers optimized views and functions to expose security information.
Noteworthy References for SQL Server Security:

Various tables and links provided cover topics from configuring firewalls to security catalog views and functions. Follow these references for detailed insights on each topic.

.NET and C# Security Best Practices

Strong Type System:

C#’s strong type system inherently reduces a lot of potential errors that could lead to vulnerabilities. Ensure you define precise types and use them consistently.

ASP.NET Identity:

For web applications, utilize ASP.NET Identity for user management. It offers features like password hashing, two-factor authentication, account lockout, and more.

Avoid SQL Injection:

Use Entity Framework (EF) or another ORM which inherently protects against SQL injection by using parameterized queries. Avoid string concatenation for SQL commands.
If you’re using ADO.NET directly, always use parameterized queries.

Cross-Site Scripting (XSS) Prevention:

In ASP.NET web applications, use Razor views, which encode data by default to prevent XSS.
Avoid using functions that can introduce XSS vulnerabilities, like Html.Raw() in Razor views, unless you’re sure about the content’s safety.

Cross-Site Request Forgery (CSRF) Prevention:

ASP.NET Core’s MVC and Razor Pages have built-in CSRF protection using anti-forgery tokens. Ensure that you’re using [ValidateAntiForgeryToken] attribute on POST actions.

Use the Principle of Least Privilege:

Run your applications with the minimum required permissions. Avoid running applications as an administrator or superuser unless absolutely necessary.

Secure Configuration Management:

Use the built-in .NET Core configuration providers, like appsettings.json, environment variables, Azure Key Vault, etc. Ensure secrets aren’t stored in code or configuration files but in secure secret management tools.

Input Validation:

Always validate input data. The Data Annotations in .NET provide a straightforward way to validate models in ASP.NET applications.

Code Access Security (CAS):

Although less prominent in newer versions of .NET, CAS can set permissions at a granular level for assemblies. Understand its implications if you’re working with .NET Framework.

Secure Session and Authentication Management:

In ASP.NET applications, use secure cookies and ensure they’re transmitted over HTTPS. Utilize built-in cookie-based authentication mechanisms and set appropriate cookie properties (HttpOnly, Secure).

Ensure Data Protection:

Use the built-in .NET Core Data Protection system for encrypting sensitive data, especially if you’re handling things like authentication tokens or other secure data outside of user passwords.

Use HTTPS:

Always use HTTPS, especially for web applications. ASP.NET Core provides easy-to-use mechanisms to enforce HTTPS.

Logging and Monitoring:

Utilize built-in logging mechanisms, but ensure sensitive data isn’t logged. Tools like Serilog or NLog can be integrated with .NET apps.

Regular Updates:

Keep your .NET runtime and all associated libraries up-to-date. Security patches are regularly released.

Avoid Buffer Overflows:

While .NET inherently manages memory for you, be cautious when using unsafe code blocks, pointers, or P/Invoke, as these can introduce potential buffer overflows.

Role-Based Access Control (RBAC):

Utilize built-in mechanisms for role-based access control, especially in ASP.NET applications, to ensure users can only access appropriate resources.

ClickOnce Deployment:

If you’re deploying desktop applications with ClickOnce, utilize its built-in features like automatic updates and permission elevation to maintain security post-deployment.

Secure Deserialization:

Be cautious with object deserialization. Avoid deserializing objects from untrusted sources to prevent potential attacks.

Dispose of Objects Properly:

Use the Dispose method or using statements to properly dispose of objects, especially those holding sensitive data or resources.

Updating the Framework with Windows Update service: The .NET Framework is kept up-to-date by Microsoft with the Windows Update service. Developers do not normally need to run separate updates to the Framework. Individual frameworks can be kept up to date using NuGet.

Windows Data Protection API (DPAPI): Use the Windows Data Protection API (DPAPI) for secure local storage of sensitive data. Use a strong hash algorithm. Make sure your application or protocol can easily support a future change of cryptographic algorithms. Use NuGet to keep all of your packages up to date.

General Security: Lock down the config file. Remove all aspects of configuration that are not in use. Encrypt sensitive parts of the web.config using aspnet_regiis -pef.

ASP NET Web Forms Guidance: Always use HTTPS. Enable requireSSL on cookies and form elements and HttpOnly on cookies in the web.config. Implement customErrors. Make sure tracing is turned off. Use ViewStateUserKey to protect against CSRF attacks.

ASP NET MVC Guidance: Use ASP.net Core Identity. Set secure password policy. Set a cookie policy. Protect LogOn, Registration and password reset methods against brute force attacks by throttling requests. Use Anti-Forgery-Tokens for every POST/PUT request.

XML External Entities (XXE): XXE attacks occur when an XML parse does not properly process user input that contains external entity declaration in the doctype of an XML payload. Use secure XML Processing Options for .NET.

Broken Access Control: Authorize users on all externally facing endpoints. Use System.Web.Security.Roles.IsUserInRole to check roles. Use the ASP.NET Membership provider and role provider, but review the password storage.

Security Misconfiguration: Ensure debug and trace are off in production. Do not use default passwords. Redirect a request made over Http to https. Ensure headers are not disclosing information about your application.

Insecure Direct object references: When you have a resource (object) which can be accessed by a reference, ensure that the user is intended to be there.

Sensitive Data Exposure: Use a strong hash to store password credentials. Use a strong encryption routine such as AES-512 where personally identifiable data needs to be restored to its original format. Use TLS 1.2 for your entire site. Get a free certificate from LetsEncrypt.org.

Summary

This blog post explores essential security best practices for various technologies commonly used in software development. Here’s a summarized checklist to keep your applications safe:

General Security

Always use HTTPS for secure communication.
Validate user input on both server and client side to prevent injection attacks (SQL injection, XSS).
Implement strong authentication and authorization mechanisms (e.g., role-based access control).
Regularly update software and libraries to patch vulnerabilities.
Use secure coding practices to avoid common security pitfalls.
Follow the principle of least privilege: grant users only the minimum permissions they need.
Store sensitive data securely (e.g., encryption).
Monitor and log activity to detect suspicious behavior.