I am developing a web app and wanted it to be secure from attacks from the application layer.

Currently, my website is allowing interception from Burpsuite like certificate proxy software. Is there a way to block requests from frontend whenever we run the website on an insecure certificate?

If that is not possible, can I detect an insecure SSL certificate from the frontend using JS?


  • 1
    PS: BurpSuite doesn't do introspection; it does (specifically) interception, or (more generally) inspection. Commented Oct 12, 2020 at 6:45
  • 2
    If you choose to do this, for the love of God make sure your app clearly reports that that's the reason it's refusing to work. I've spent one too many weeks trying to debug an issue because the software flat out didn't tell me it didn't trust a cert. Commented Oct 13, 2020 at 4:41
  • thanks @Shadur you have given me one more reason for avoiding this.
    – Bond 007
    Commented Oct 13, 2020 at 4:47

2 Answers 2


... wanted it to be secure from attacks from the application layer. ... website is allowing introspection from Burpsuite ... detect an insecure SSL certificate from the frontend using JS?

Based on your previous question you want to protect your application against reverse engineering and manipulation by the end user itself, i.e. the user controlling the client (browser).

But you cannot use a transport protection (TLS, HTTPS) to protect against manipulations at the endpoint of the communication. You can try to protect against reverse engineering the protocol and manipulating the traffic by a man in the middle proxy, but you cannot protect against somebody intercepting the communication before encryption and after decryption in a manipulated client, since you don't have full control about which clients are used.

Apart from that certificates from Burpsuite are not necessarily insecure. Once the issuing proxy CA is imported as trusted into the browser, the issued certificates are considered as valid and secure as certificates issued by a public CA. Thus basing the protection on the validity or security of the certificate would not protect against the end user itself intercepting the communication.

And even if one manages to get access to the certificate from JS to check if it is exactly the expected one, the code to do this would first need to pass the intercepting proxy and could be manipulated there to disable the checks or simply lie.

In other words: as long as one cannot fully control the client one should never trust the client to behave as expected. Any critical computation should be done at the server, all data sent from the client should be validated and critical state should be held at the server or be protected (like with HMAC) by secrets only known to the server.

  • Thanks again, I have a clear image now. Are you concluding that providing security by checking certificates at the frontend is not a good enough idea instead I should care about security at backend itself so that nothing is compromised?
    – Bond 007
    Commented Oct 12, 2020 at 9:23
  • 4
    @Bond007: Correct. You cannot trust the front end since you don't fully control it. Commented Oct 12, 2020 at 10:23
  • 1
    I am getting some interest in the security field & have some more questions now thanks to you mate.
    – Bond 007
    Commented Oct 12, 2020 at 10:30

HTTP Strict Transport Security (HSTS) RFC 6797:

8.4. Errors in Secure Transport Establishment

When connecting to a Known HSTS Host, the UA MUST terminate the connection (see also Section 12 ("User Agent Implementation Advice")) if there are any errors, whether "warning" or "fatal" or any other error level, with the underlying secure transport.

This removes the ability to bypass the warning or add a security exception. However, there wouldn't technically be an error, if the user has installed the root CA of an intercepting proxy. Therefore, it protects your users from MitM, but doesn't protect your web application.

  • Alas for the removal of certificate pinning. That would do something here.
    – Joshua
    Commented Oct 12, 2020 at 16:55
  • 4
    Not really. The end user could simply clear the browser's HPKP data and/or have their proxy strip the HPKP headers, rendering it entirely useless.
    – josh3736
    Commented Oct 12, 2020 at 18:29
  • 1
    @Joshua: Also, HPKP was removed for a reason, as it caused more problems than it solved. With HPKP it's just way too easy to make permanent damage. Commented Oct 13, 2020 at 10:47

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .