Short answer - but read below !!!
import os
origin = os.environ.get("REMOTE_HOST")
Some considerations: Pure CGI is not an interesting technology to use in 2018. It was implemented in "pre-web 1.0" times - in addition to drastic performance problems, it is a time when "all web applications have to implement everything ": do all the session code, security, input verification, manually map your data to Python objects, write them to the database (or other means)
From the time CGI was most commonly used for today's complexity - and forms of attack to - WEB applications have been multiplied by more than 100 times. As an example, a CGI request creates a new process, with a new Python interpreter, for each page request via HTTP. For about 10 years now, even using a system thread (reusing the Python interpreter and process) is considered "overkill" - although it's still okay for apps without too much traffic.
Understand what happens: web server CGI engines populate the "REMOTE_HOST" environment variable with the contents of the HTTP "Origin" field. (You can even call cgi.print_environ_usage()
to see other interesting environment variables).
However, as "security mechanism" this variable and nothing are the same thing. The "Origin" field is placed in the http header - in the normal operation of the application, this is done by the user's browser, which fills the field with the domain in the site. However, anyone connected to the internet can make a "post" or "get" request to your server by filling in http headers, including "origin", however they want. This is actually one of the features of the http protocol as it allows the implementation of APIs.
When creating a WEB application you have to be aware that anything that arrives on your server can come from anywhere on the internet, and with any content.
The only thing you can guarantee is that at some point, before sending you a response, the HTTP client made another request to your server (for example, to retrieve the html from the form itself) - this is made by the use of cryptographic tokens. But keep in mind that the entire code of the page is under the control of third parties: no restriction of the values sent by the client, nor validation nor anything can be guaranteed: the client "browser" is free to create a completely arbitrary "POST" for his application.
Throughout the decades (decades after the creation of CGI, by the way) of web applications, web frameworks have evolved, incorporating code that either implements alone or encourages the use of good security practices. The type of "attack" you are thinking about, for example, is mitigated by the use of "Cross Site Request Forgery" token verification, and is placed (almost) automatically by all active development frameworks. And it's an "attack", unlike an arbitrary "POST" made by an API, so it could be used to embed posts to your website from maliciously embedded javascript on any other web page - thus a user of your site who visited another page could have the data stolen or tampered with.
So, the recommendation is: Okay to play around with CGI to understand the mechanisms. But as soon as possible, and especially, do not put any applications on the air: use a web framework like flask, Django, Bottle and Python 3 (Python 2 is also an obsolete technology that is about to be completely retired. Linux, Python 3 is available by simply typing "python3" instead of Python)