TLS configuration
Deprecated protocols, weak ciphers and certificate issues that downgrade or break encryption.
Technology Security
Nginx sits in front of almost everything, which makes its configuration a security control in its own right. A single misconfigured location block or a weak TLS setting undermines everything behind it.
Because every request passes through it, Nginx decides how strong your transport encryption is, whether the browser is told to enforce sensible protections, and what internal detail leaks to the outside. Get its configuration wrong and you can expose the very services it was meant to protect.
We review the configuration and the live behaviour together — the TLS it actually negotiates, the headers it actually sends, the paths it should not serve, and the proxy rules that can be turned against the backend. Findings are confirmed and delivered as specific configuration changes.
Coverage
The configuration issues that weaken everything behind the proxy.
Deprecated protocols, weak ciphers and certificate issues that downgrade or break encryption.
The response headers that enforce transport security, framing control and content-type handling in the browser.
Server-status pages, config files and backups reachable from the outside.
Location and alias rules that let a request read files outside the intended root.
Request-handling rules that can be abused to reach internal services or smuggle requests.
Version banners and error output that hand an attacker their reconnaissance for free.
Outdated builds with known vulnerabilities.
Deliverables
The report is the product. If it cannot be acted on by a developer and understood by a director, we have not finished.
Each issue with the exact directive to change.
A known-good transport and header configuration.
The changes that close exposure and disclosure, in priority order.
Confirmation the corrected configuration behaves as intended.
How we work
The same engagement model applies to every piece of work we take on, so you always know what happens next.
A 30-minute call, then a written scope: what is in, what is out, what we need from you and what it costs. Nothing starts before you sign it.
Rules of engagement, testing windows, escalation contacts and a signed authorisation. Out-of-hours windows where production cannot take the load.
Automated coverage first, then manual testing where judgement is required. Critical findings are reported the day we confirm them, not at the end.
One report a developer can act on and an executive can read, with evidence, reproduction steps, business impact and a fix for every finding.
A walkthrough call with your engineers. We answer questions on the fix, not just the finding.
A free retest cycle to confirm the fixes hold, and a clean summary you can hand to a customer, auditor or board.
Questions
The questions clients actually ask during scoping. If yours is not here, ask it directly.
Both, where you can share the configuration. The live behaviour shows what the server actually negotiates and serves; the config shows why, and where else the same mistake was made.
It is complementary. An application test focuses on the app; this focuses on the layer in front of it — the TLS, headers and routing that a web test often treats as a given.
Yes, and that is exactly where proxy misconfiguration matters most, because one bad rule can expose or be used to reach any service behind it.
Next step
A 30-minute call, then a scope document with what is in, what is out and what it costs. No obligation, and no charge for the conversation.