Skip to main content
Version: 8.2405.x.x RR

Security feature checklist

Use the following checklist to document the security features which have been activated for your configuration.

  • All application resources (hosts, URLs) are integrated into nevisProxy and no longer directly accessible from the internet.
  • HTTPS is used to encrypt the traffic between the client and the proxy server. Only secure cipher suites are allowed to be used.
  • Key management processes have been defined.
  • Connection and keep-alive timeouts have been defined.
  • TCP DoS prevention has been enabled.
  • Log level is set to notice and OP tracing has been enabled.

Level 1, TCP, TLS and DoS protection​

  • Protocol validation and restriction filters have been activated for the HTTP request line (methods, length).
  • Protocol validation and restriction filters have been activated for the HTTP request headers (validation patterns, size restriction, names).
  • Protocol validation and restriction filters have been activated for the HTTP request body (size).
  • Filters for the HTTP response headers have been defined (names).
  • Error filter has been activated.
  • Cookie manager/filter has been configured and activated.
  • Cache filter has only been activated for public content (anonymous access).
  • Numbers of concurrent requests per application have been limited.
  • Brute force detection, limiting the number of rule violations per client IP, has been activated

Level 2, HTTP protocol validation and acceleration​

  • Only known URIs have been configured to be accessible by the client (no access to the "/" path).
  • User authentication has been enabled for all applications requiring authentication.
  • Session timeouts and store size have been defined.
  • Uses secure client session identification.
  • Session DoS prevention has been enabled.
  • Proxy uses secure cookie and sets the httponly flag.
  • Brute force detection, limiting the number of failed login attempts, has been activated.
  • Navajo cookie is locked to additional client attributes.

Level 3, Session management and user authentication​

  • Input validation blacklists has been activated (XSS, SQL, other).
  • Input validation whitelists has been defined for request lines.
  • Input validation whitelists has been defined for request lines and body.
  • XML and SOAP validation is used for Web service calls.
  • XML or JSON validation URL and HTTP method white-listing is used for RESTful services.
  • URL encryption/signing filter has been activated.
  • Form signing has been activated.
  • CSRF protection has been enabled (session id injection, referrer header check, POST/GET filter).
  • HTTP security headers are configured.

Level 4, application-specific content filtering​

  • Make sure the TestServlet is not configured in production.
  • Make sure the DefaultServlet does not point to the default index.html but to your entry point URL.
  • Replace default error pages with your own error pages.
Last updated on