Your Legacy Application Failed a Client Security Review

Sort every finding into one of two groups. Configuration findings close in days. Architecture findings need a plan with dates. Most reviews of older .NET applications return more of the first group than expected.

Configuration findings

These are typically fixed in web.config, IIS or at a proxy, without changing application code.

• Missing security headers. HSTS, X-Content-Type-Options, X-Frame-Options or a frame-ancestors policy, Referrer-Policy. Add them under httpProtocol/customHeaders or at the reverse proxy. A full Content-Security-Policy takes longer, so start it in report-only mode.
• TLS 1.0 and 1.1 enabled, weak ciphers. Disable them in the Windows registry or at the load balancer. Test outbound calls afterward. Applications targeting .NET Framework versions before 4.7 may need a setting to use TLS 1.2.
• Cookies without Secure, HttpOnly or SameSite. Set requireSSL and httpOnlyCookies in web.config and the equivalents for forms authentication.
• Version disclosure. Remove the Server, X-Powered-By and X-AspNet-Version headers.
• Verbose errors and debug mode. Turn customErrors on and set debug="false".
• Vulnerable libraries with a compatible update. jQuery, Bootstrap, Newtonsoft.Json and similar. A minor-version update needs a regression pass and little else.

Architecture findings

• An operating system, .NET version or database past end of support.
• A component with known vulnerabilities and no supported upgrade.
• No multi-factor authentication or single sign-on, weak password storage.
• SQL built by string concatenation.
• No audit logging of who did what.

These take weeks or months. A reviewer generally accepts a dated remediation plan together with compensating controls: a web application firewall, network restrictions, and monitoring.

Process findings

Many questionnaires ask more about process than code: patch cadence, access reviews, backup restore tests, an incident response plan, log retention. These are closed by writing down the practice and following it. They are often the cheapest items on the list.

A 30-day sequence

• First 48 hours. Read every finding. Label each one configuration, architecture or process. Ask the reviewer which are blocking and which can be accepted with a plan.
• Week 1. Close the configuration findings in a test environment, then production. Re-scan.
• Week 2. Update the libraries that have compatible versions. Write the process documents.
• Week 3. For each architecture finding, write the remediation plan with an owner and a date, and put the compensating controls in place.
• Week 4. Respond with evidence: scan results, configuration screenshots, the plan.

When the same architecture finding appears in every review, the platform is costing you deals. When an internal portal becomes a liability covers how to make that case.