Secure Coding Standards · SEC-01

This group of standards is designed to ensure the technology, language, framework or packages used to build software for Audacia’s clients are as secure and easy to maintain as possible.

Use long-term support framework versions · SEC-01.1.1 · MUST · DEV/TEST

Applications must target long-term support (LTS) versions of major frameworks (e.g. .NET or Angular).

Using LTS versions of frameworks improves an applications security, as LTS releases receive security patches and updates for a longer period than standard term support versions. For .NET applications, Microsoft provides LTS releases with 3 years of patching support.

Avoid the use of libraries with known vulnerabilities · SEC-01.1.2 · MUST · DEV/TEST

Applications must not utilise external libraries with known vulnerabilities (e.g. older versions of jQuery).

The use of external libraries should be carefully monitored, reviewed, and virus scanned in order to reduce the risk of malicious code injection (for example, cross-site scripting injection).

Use secure package versions · SEC-01.1.3 · SHOULD · DEV/TEST

Applications must maintain the security and reliability of all libraries and packages by upgrading to the latest secure version.

If a vulnerability is discovered, then it should be upgraded to the latest, patched version as soon as one becomes available.

Vulnerabilities can propagate through indirect dependencies or outdated packages - any packages which cannot be upgraded to secure versions must be recorded as a risk within the project tracker.

Use strict code compilation · SEC-01.1.4 · SHOULD · DEV

All code must be compiled to the highest warning level available to the compiler.

These warnings should be investigated to ascertain a severity, before they have the potential to become logic errors or security vulnerabilities, where critical vulnerabilities and warnings are actioned as soon as possible.

All application credentials must follow the Password and Authentication Policy · SEC-01.2.1 · MUST · DEV/TEST

To ensure password complexity, passwords must adhere to Audacia’s ‘Password and Authentication Policy’

Application credentials must not be re-used · SEC-01.2.2 · MUST · DEV/TEST

Unique, auto-generated passwords should be used to ensure the same password cannot be reused for accounts across multiple applications.

Un-encrypted credentials must not be stored in source control · SEC-01.2.3 · MUST · DEV/TEST

All credentials (not limited to API keys, default application logins or database config) must not be stored in source control.

If encrypted credentials are stored in source control, the necessary decryption key(s) must stored securely elsewhere.

Passwords must be salted/hashed before being stored · SEC-01.2.4 · MUST · DEV

Passwords must never be stored in plaintext. If an application manages authentication itself, any passwords must be salted and hashed before being stored.

Passwords or personal information must be obfuscated before being logged · SEC-01.2.5 · MUST · DEV

If any data containing personal information or a password is being logged, this should be obfuscated (replaced with ”****” or an empty string) before being logged. If information about who performed a certain action is to be logged, instead use database-generated user ID or similar identifier.

Emails must not send information to external sources · SEC-01.2.6 · MUST · DEV

Test emails must use one of the following approaches

• Use a domain that is recognised as invalid such as @example.com or .test
• Use your Audacia email with plus addressing so create alternative emails. For example audaciaemail+{stringvalue}@audacia.co.uk

Validate, encode or escape user input to prevent cross-site scripting (XSS) · SEC-01.3.1 · MUST · DEV/TEST

Any data entered by a user must be treated as untrusted.

All untrusted input must be validated, escaped or encoded appropriately when being rendered in a HTML page as this defends against cross-site scripting (XSS).

Server-side input validation must be performed,to ensure that malicious or malformed data is not processed. This is in addition to client-side validation, which can be by-passed.

Automated API tests should be written for input validation

Functional API tests can validate business logic rules around field length, required fields and expected data types faster than UI tests which need to login or navigate to the form or page under test.

Use request verification tokens to prevent cross-site request forgery (CSRF) · SEC-01.3.2 · MUST · DEV

Applications must use request verification tokens (anti-forgery tokens) to validate all requests.

Request verification tokens protect against data tampering i.e. if an attacker modifies form data, the token validation will fail, rejecting the request.

Utilise parameterized queries to prevent against SQL injection · SEC-01.3.3 · MUST · DEV

Always use parameterized queries if executing SQL directly from code (although an ORM or, failing that, a stored procedure with no unparameterized dynamic SQL should be preferred for any data access).

Applications should utilise virus scanning · SEC-01.3.4 · SHOULD · DEV

All systems that use file upload functionality, should have anti-virus configured and tested.

File upload architectures must be documented · SEC-01.3.5 · MUST · DEV

The anti-virus configuration and file upload architecture should be documented in the projects Architectural Decision Records.

Do not serialized objects from untrusted sources · SEC-01.3.6 · MUST · DEV

Applications must not accept serialized objects from untrusted sources to prevent against remote code execution attacks.

If this is not possible, one or more of the following strategies should be adopted to avoid insecure deserialization:

• Implementing integrity checks such as digital signatures on any serialized objects to prevent hostile object creation or data tampering.
• Enforcing strict type constraints during deserialization before object creation as the code typically expects a definable set of classes.
• Log deserialization exceptions and failures, such as where the incoming type is not the expected type, or the deserialization throws exceptions.

Adopt rate limiting on all endpoints · SEC-01.4.1 · MUST · DEV

Applications must employ rate limiting on all endpoints to mitigate against brute force attacks, prevents server overload and DoS.

If the system utilises a Web Application Firewall (WAF) then rate limiting should be implemented in the WAF, the AspNetCoreRateLimit NuGet package provides a coded alternative.

Rate limiting decisions should be documented · SEC-01.4.2 · SHOULD · DEV

Weather all requests made to an API are rate limited or limits are applied to each API URL or HTTP verb and path, this should be documented in the projects Architectural Decision Records.

Access to resources should be granted on the principle of least privilege.

Access and authorisation must be restricted · SEC-01.5.1 · MUST · DEV

Features and system areas must be protected by roles, that give users the permissions to access only required areas/information.

If necessary authorization should be applied to specific data to prevent ID enumeration.

API endpoints must be authenticated by default · SEC-01.5.2 · MUST · DEV

Endpoints should be authenticated by default and anonymous access should have to be explicitly granted, for example to a ‘login’ endpoint.

APIs must enforce the same-origin policy · SEC-01.5.3 · MUST · DEV

APIs must enforce the same origin policy. If an API is hosted on a different domain/subdomain to a front-end application then this can be relaxed, but only to allow those specific origins as required.

Testing should ensure it is not possible to access resources using URL manipulation · SEC-01.5.4 · SHOULD · TEST

User’s must not be able to manipulate URLs and entity IDs in API requests to gain access to data they are not authorised to view.

Testing should ensure data is not exposed · SEC-01.5.5 · SHOULD · TEST

The system should only return the data that is required by the end user. It should not return any data the user is not authorised to view or any data the user does not need to fulfil their current action.

Data minimisation can be achieved by ensuring the system does not return more table columns and/or data than will be shown to the user.

Applications must only share sensitive information with the relevant audience.

In some cases, applications should be intentionally obscure with the information provided to the end user, for example, data exposure can be avoided in authentication messages. If a user enters an incorrect username or password, the system should not tell the user which is incorrect. This helps reduce the likelihood of a bad actor being able to guess valid username/password combinations.

Web applications must define a content security policy (CSP) · SEC-01.6.1 · MUST · DEV

A Content Security Policy header is used to define where assets such as scripts and stylesheets can be loaded from and whether inline execution of such as assets is allowed.

The Audacia.SecureHeadersMiddleware library contains a configurable Content Security Policy for .NET apps.

Web applications must include and exclude HTTP headers following security best practices · SEC-01.6.2 · MUST · DEV

Certain HTTP headers are recommended to be present in (or absent from) all responses for security reasons -see OWASP recommended HTTP headers.

The Audacia.SecureHeadersMiddleware library contains a configurable ASP.NET Core middleware to add the appropriate headers for .NET apps. It also has default configuration for APIs and MVC applications.

Web applications must include the relevant HTTP headers when there are SEO considerations · SEC-01.6.3 · MUST · DEV

Use the X-Robots-Tag meta HTTP tag, which tells web crawlers what they are allowed to do when they visit a site (and are more highly valued than a robots.txt file).

The appropriate OWASP guidance must be followed · SEC-01.7.1 · MUST · DEV/TEST

Teams must follow current OWASP guidance relevant to the system and document the risks considered and the controls applied.

• OWASP Top 10: Common web application risks (e.g. injection, broken access control, cryptographic failures, insecure design, vulnerable and outdated components, SSRF). See the OWASP Top 10.
• OWASP Top 10 for LLM Applications: Risks specific to LLM systems (e.g. prompt injection, data poisoning, supply chain/model integrity, sensitive information disclosure). See the OWASP Top 10 for LLM Applications.
• OWASP Top 10 for Business Logic Abuse: Abuse of workflows and rules (e.g. bypassing business processes, DoS, privilege escalation through logic flaws, quota/metering circumvention). See the OWASP Top 10 for Business Logic Abuse.