Clickjacking in Restify with Mutual Tls

Clickjacking is a client-side UI redress attack where an attacker tricks a user into interacting with a hidden or disguised element inside an invisible or obscured iframe. In Restify, enabling Mutual Transport Layer Security (mTLS) changes how clients authenticate to the server—each side presents a certificate—but it does not change how browsers enforce framing rules. mTLS protects channel authenticity and peer identity, yet it does nothing to prevent a victim’s browser from loading a malicious page that embeds your Restify application in an iframe if HTTP response headers do not prohibit it.

When a Restify server opts into mTLS, the TLS handshake requires client certificates. While this ensures only authorized clients connect, it does not affect the browser’s rendering behavior. An attacker can still host a page with an iframe pointing to a Restify endpoint that lacks anti-clickjacking headers. The browser will load the iframe regardless of mTLS because the framing decision happens after the TLS handshake, at the HTTP layer. If the Restify app delivers sensitive actions—such as changing account settings or authorizing payments—within frames, a forged UI can overlay transparent or disguised controls, leading to unauthorized operations despite mTLS being in place.

Complicating matters, some organizations assume mTLS alone satisfies transport security and neglects frame-protection headers. In a black-box scan, middleBrick tests unauthenticated attack surfaces and can detect whether Restify responses include Content-Security-Policy frame-ancestors or X-Frame-Options. Without these, the API remains exposed to clickjacking even when mTLS is enforced. OWASP API Top 10 A05:2023 Security Misconfiguration and A01:2027 Broken Access Control align with this risk, as missing framing controls are a misconfiguration that exposes UI interactions regardless of strong transport authentication.

To illustrate, consider a Restify endpoint that renders an HTML page with a sensitive form. If X-Frame-Options or Content-Security-Policy is absent, an attacker can craft a page like <iframe src="https://api.example.com/transfer" style="opacity:0;position:absolute"></iframe> and lure users who present valid client certificates. The user’s mTLS credentials are used to establish the TLS session, but the framing exploit occurs independently. middleBrick’s LLM/AI Security checks do not apply here; this is a classic web UI issue in an API server, detectable via unauthenticated scans that review HTTP headers and identify missing frame-protection directives.

Remediation focuses on two layers: ensuring mTLS is correctly configured in Restify and adding anti-clickjacking HTTP headers. mTLS in Restify requires the server to request and validate client certificates during the TLS handshake. Below are concrete, working examples for Restify using the tls module and secure headers.

First, configure Restify to require client certificates. Use the tls.createServer options to specify the CA, server certificate, and key, and set requestCert and rejectUnauthorized to enforce client validation.

const restify = require('restify');
const fs = require('fs');
const tlsOptions = {
  cert: fs.readFileSync('/path/to/server-cert.pem'),
  key: fs.readFileSync('/path/to/server-key.pem'),
  ca: [fs.readFileSync('/path/to/ca-cert.pem')],
  requestCert: true,
  rejectUnauthorized: true
};
const server = restify.createServer({
  tlsOptions: tlsOptions
});
server.get('/secure', (req, res, next) => {
  res.send({ message: 'mTLS authenticated' });
  return next();
});
server.listen(8080, () => {
  console.log('mTLS Restify server listening on port 8080');
});

Second, add anti-clickjacking headers to every response. Use a per-route or global middleware to set X-Frame-Options and Content-Security-Policy frame-ancestors. For a Restify service, a simple plugin or use of server.use ensures these headers are present regardless of endpoint logic.

server.use((req, res, next) => {
  res.setHeader('X-Frame-Options', 'DENY');
  res.setHeader(
    'Content-Security-Policy',
    "frame-ancestors 'none'"
  );
  return next();
});

With these headers, browsers will refuse to render the Restify page in an iframe, effectively mitigating clickjacking. The combination of mTLS and framing controls ensures channel security and UI integrity. Note that Content-Security-Policy frame-ancestors is the modern standard; X-Frame-Options provides legacy compatibility. middleBrick’s scans can verify that these headers exist and are not overridden by later middleware.

Finally, validate that client certificates are properly verified by testing with invalid or missing certs. Restify should reject such connections when rejectUnauthorized is true. This protects backend endpoints while the framing headers protect the user experience. In a Pro or Enterprise plan, middleBrick’s continuous monitoring can alert you if headers are missing after deployments, ensuring remediation guidance remains actionable across versions.