How to block requests in web app when certificate is insecure?

... 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.

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.