Your password is not secure if you just send it with POST - still visible and unencrypted, albeit a tiny bit less obvious.
Sending an unencrypted password via POST is the most insecure, yet still relatively sane way of doing this. (yes, there are less secure ways, but those are completely insane - sending a password form through GET is about as secure as broadcasting it on TV or printing it in the newspaper).
This is what a typical GET request looks like:
GET http://somedomain.example.com/path/file?here=are&the=GET¶meters=.
X-Some-Header: header content
X-Another-Header: 1
Here's a similar POST request (note that you can send both GET and POST parameters in a POST request):
POST http://somedomain.example.com/path/file?here=are&the=GET¶meters=.
X-Some-Header: header content
X-Another-Header: 1
Content-Length: 40
with_POST&=the&content=is&here_in=the&request=body
As you can see, HTTP is a completely plaintext protocol - there is no encryption performed on the data, so anyone can view and/or modify it in transit. Access to the code is not necessary at all - just watch the traffic and your data will be there, for anyone to see (you can verify this with tools such as Wireshark which allows you to view network traffic).
To remove this need to trust the whole world, HTTPS (S is for Secure) was created, which provides encryption ("only the sender and receiver can read it") and authentication ("the server is indeed yourserver.example.com, and not evilserver.example.net").
HTTPS is a wrapper around HTTP: where with HTTP, the client connects to the webserver and starts the conversation, HTTPS first establishes a secure SSL tunnel, and the HTTP communication goes through that. Setting up a HTTPS server is a bit more complex than HTTP, see e.g. this article.