One of our security audit companies performed the security audit with our custom-hosted AWS live instance. This security audit was performed using a grey-box method. Grey-box testing refers to a method where the tester has limited knowledge of the system being attacked. The goal of the grey-box penetration test is to simulate a malicious user or an external cyber attack

Below is a short summary of some of the principal findings from the security audit

1. Timing-based account enumeration
Category: Enumeration

A valid account takes approx. 300-400ms for the server to respond to a login. The invalid account would take the server 100-120ms to respond to a login. This timing difference allows figuring out the existence of accounts

Mitigation - (The action of reducing the severity)
- Refactor the authentication code to ensure that login transactions are processed within the same
duration.
- Avoid providing any verbose details around what accounts may or may not exist within the web
application

2. Missing Site-wide CSRF token
Category: Improper Data Validation

CSRF tokens are missing in critical/sensitive actions such as password resets, adding accounts, etc.

Mitigation - (The action of reducing the severity)
Ensure all web application form submissions leverage a CSRF token

3.No Exception handling, server in debug mode throwing internal python errors
Category: Misconfiguration / Information Disclosure

Stack traces and error logs being sent to the client-side will allow an attacker to gain valuable information about the webserver system

Mitigation - (The action of reducing the severity)
-When running the web application in production it is highly recommended to disable debug mode
-Prevent sharing system information in responses by integrating proper exception handling and fail
safes

4. Missing Session Cookie Security Flags
Category: Improper Session Management

The session cookie session_id is not set with the Secure, HTTP_ONLY, SameSite flags.

Mitigation - (The action of reducing the severity)
The secure flag should be set on all cookies that are used for transmitting sensitive data when
accessing content over HTTPS. If cookies are used to transmit session tokens, then areas of the application that is accessed over HTTPS should employ their own session handling mechanism, and the session tokens used should never be transmitted over unencrypted communications.

Wildcard CORS Policy allows access from any origin
Category: Misconfiguration

Cross-Origin Resource Sharing (CORS) is an HTTP-header based mechanism that allows a server to indicate
any origins (domain, scheme, or port) other than its own from which a browser should permit loading
resources.

Mitigation - (The action of reducing the severity)

To mitigate the risk of CORS, we always recommend whitelisting your Access-Control-Allow-Origin instead of wildcarding. With whitelisting, the scope of your Access-Control-Allow-Origin will be limited to only the sites that deal directly with your primary site or API and exclude any of your sites that do not.

Please guide me on how I can achieve all these from the technical perspective and overcome all these situations