I agree with Steffen Ullrich's answer - blacklisting leaves too many holes, and it will only be a matter of time until you encounter an unexpected "Gotcha". This is true in general for security, as proper defense in depth should start from the perspective of least privilege. Rather than asking "What shouldn't the user do?" it's much safer to ask "What should the user do?" and stop everything else.

I'll add to your list though as there is another very dangerous avenue that you would need to watch out for if you are blacklisting, and this example should help bring home the importance of white-listing.

##Metadata Endpoints in Cloud Hosting Environments##

Something relatively new introduced to cloud hosting environments are meta-data URLs designed to aid in CI/CD and related infrastructure maintenance. These API endpoints are internal-only endpoints that give VPS's and other kinds of computing resources information about themselves, including the access keys that were used to launch them.

These guys are quite complicated, and they are an ideal endpoint for hackers who find an SSRF vulnerability. Moreover, none of the rules you mentioned in your post would block access to them. Some brief details:

1. For Google Cloud the Metadata URL lives at http://metadata.google.internal/computeMetadata/v1/project/. Docs are here.
2. For AWS the Metadata URL lives at http://169.254.169.254/latest/meta-data/. Docs are here.

To make it clear that these things are quite dangerous:

1. Here is a bug report that goes into abusing a metadata endpoint in detail
2. And here is a very short summary of a bug report on hackerone where Shopify paid out $25,000 as a result of an SSRF vulnerability that gave access to the metadata endpoint on AWS, leading quickly to full root privileges for the attacker.

##Summary##

The take away here isn't just that metadata endpoints are dangerous (they are, and if you are hosting in a cloud environment then you need to know about them). Rather, the point is that blacklisting is not a very effective strategy. These metadata endpoints aren't blocked by any of the rules in your original post, but they are very dangerous, and vary from hosting provider to hosting provider. That means that you may have what seems to be a completely effective blacklist, but doing something as innocuous as switching hosting providers may end up making you completely vulnerable once again.

In short, the list of "dangerous" things you need to block can be endless. The list of actual things your application needs to do is probably much shorter. Unless you have a very compelling reason, it's much easier to focus on the list of things you are supposed to do, instead of the infinite list of things you shouldn't do.

I agree with Steffen Ullrich's answer - blacklisting leaves too many holes, and it will only be a matter of time until you encounter an unexpected "Gotcha". This is true in general for security, as proper defense in depth should start from the perspective of least privilege. Rather than asking "What shouldn't the user do?" it's much safer to ask "What should the user do?" and stop everything else.

I'll add to your list though as there is another very dangerous avenue that you would need to watch out for if you are blacklisting, and this example should help bring home the importance of white-listing.

Metadata Endpoints in Cloud Hosting Environments

Something relatively new introduced to cloud hosting environments are meta-data URLs designed to aid in CI/CD and related infrastructure maintenance. These API endpoints are internal-only endpoints that give VPS's and other kinds of computing resources information about themselves, including the access keys that were used to launch them.

These guys are quite complicated, and they are an ideal endpoint for hackers who find an SSRF vulnerability. Moreover, none of the rules you mentioned in your post would block access to them. Some brief details:

1. For Google Cloud the Metadata URL lives at http://metadata.google.internal/computeMetadata/v1/project/. Docs are here.
2. For AWS the Metadata URL lives at http://169.254.169.254/latest/meta-data/. Docs are here.

To make it clear that these things are quite dangerous:

1. Here is a bug report that goes into abusing a metadata endpoint in detail
2. And here is a very short summary of a bug report on hackerone where Shopify paid out $25,000 as a result of an SSRF vulnerability that gave access to the metadata endpoint on AWS, leading quickly to full root privileges for the attacker.

Summary

The take away here isn't just that metadata endpoints are dangerous (they are, and if you are hosting in a cloud environment then you need to know about them). Rather, the point is that blacklisting is not a very effective strategy. These metadata endpoints aren't blocked by any of the rules in your original post, but they are very dangerous, and vary from hosting provider to hosting provider. That means that you may have what seems to be a completely effective blacklist, but doing something as innocuous as switching hosting providers may end up making you completely vulnerable once again.

In short, the list of "dangerous" things you need to block can be endless. The list of actual things your application needs to do is probably much shorter. Unless you have a very compelling reason, it's much easier to focus on the list of things you are supposed to do, instead of the infinite list of things you shouldn't do.