about the possibility of being attacked

The option you are configuring is only configured as a client and is not directly related to server security.

How do you use git as a client on the server?I can't say anything unless I know the situation in detail.

I'm going to tell you a completely hypothetical story.For example, assume that the server and its environment are:

• The target server uses nginx to publish websites externally.
• Web content is managed by a separate, proprietary GitLab server.
• The target server periodically retrieves web content from the GitLab server using the git command and cron etc.
• The certificate installed on the GitLab server is a self-signed certificate, so certificate verification fails with normal access.
• The target server is directly connected to the Internet and has no specific communication restrictions.

In this situation, assume that the administrator of the target server has set the http.sslVerify setting in git to false to avoid certificate errors.

Now, if an attacker knows an overview of how this works (for example, a server detail design document was leaked) and can point his name to another IP, such as a DNS cache poisoning attack, the attack could succeed as follows:

There is a hurdle that DNS cache poisoning attacks must succeed, but if you manage to get them to a fake GitLab server, it can cause a lot of damage.If you could have communicated without disabling certificate verification, such as having a formal certificate in your GitLab server, you could have prevented such attacks.

Thus, even if the application is used as a client, as long as the application runs on the server, it should be carefully verified for operational purposes.If you want to loosen the security configuration, you should assume and validate any attacks that may result in them and determine if they can be configured.