im looking to allow a previously GET request of a url like:
myurl.com/site/id/1 where the value 1 in this case - is a pseudo random and not too difficult to guess.
I'm looking to bring this id/1 key/value into my request BODY .
Is this more secure by using POST and putting the key and value into the request BODY, than using GET and having it in the url ?
How can I make this even more secure?
This is a tricky question to answer because GETs might be totally fine, or might be totally broken, it depends on how you've built the security mechanisms on your API. Have a look at the OWASP REST Security Cheatsheet.
In some cases there's no difference between URL parameters in a GET, and body params in a POST. For example, take RFC 6960, the wire protocol for Online Certificate Status Requests (OCSP), appendix A.1 allows the same data to be sent in a POST or a GET (if under 255 bytes), and must be treated the same by the server.
A.1. Request
HTTP-based OCSP requests can use either the GET or the POST method to submit their requests. To enable HTTP caching, small requests (that after encoding are less than 255 bytes) MAY be submitted using GET. If HTTP caching is not important or if the request is greater than 255 bytes, the request SHOULD be submitted using POST.
In general though, I think POSTs give you more control over security. For example, many phishing attacks work by getting the user to click on a link. All browsers treat link referrals as GETs, so if a particular resource is only accessible over POST, then it's not possible to do link-based phishing attacks (or, at least, the attack requires multiple steps, like getting the user to click the link and then click a button on the phishing page).
Another win for clean separation between GETs (used only for fetching data in a "Read" type way), and POSTs (used only for modifying or storing data in a "Write" type way) is cross-site request forgery protection [source]:
In HTTP GET the CSRF exploitation is trivial. For example, a simple hyperlink containing manipulated parameters and automatically loaded by a IMG tag. By the HTTP specification however, GET should be used as a safe method, that is, not significantly changing user’s state in the application. Applications using GET for such operations should be rewritten to use HTTP POST and/or use anti-CSRF protection.
TL;DR1: It's hard to say that switching from a GET to a POST will magically give you more security, because it depends what that API endpoint is doing. POSTs do give more options for how you implement your security mechanisms and a few less attacks to worry about, but with the right understanding and attention to detail you can build perfectly secure GET APIs.
TL;DR2: It's hard to answer your question by itself, out of context of what your API is doing, and what security mechanisms you have in place (CSRF protection? How does you authentication and authorization mechanism work? etc). I would suggest that you read the OWASP REST Security Cheat Sheet and look at your API security as a whole.
I think the first place to start would be to actually make the id less guessable. IF it's a short number, there are tools out there to help attackers enumerate those ids with no knowledge of your system.
As you mention in your question, you already use HTTPs so that's great.
In general, having the parameters in the POST body help a bit -- as they're less likely to be logged into log files that can leak out of your environment. Nearly every API Gateway / Webserver will log the URL (and the path parameters) in their logs -- but very few will log the actual body as those can be very large.
It depends on your use-case of course, and what you're actually securing against.
Technically speaking GET is not less secure than POST, if both are sent without encryption they can be read.
To make this more secure you can increase the size and complexity of ID parameter to make it harder to guess. But keep in mind if this is supposed to be a public value, there's no need to go overboard with this.
Briefly: If you think that using GET discloses some data where as POST does not disclose, then your expectation is not correct. There is no difference from this point of view.
where the value 1 ... not too difficult to guess ... I'm looking to bring this id/1 key/value into my request BODY.
How can it make your application more secure?
Do you believe that if user doesn't see what you send to server then your application is more secure? Any user can see any request, including POST request. In the most browsers there is "Developer Tools", which is usually available on key F12. You cannot hide anything from users.
Or may be you believe that it some values are not the part of URL, then somebody can in the middle can read that, but the body part of the POST cannot read? It makes no sense.
If you use HTTP, then everything you send from browser is visible to everyone who can access your traffic. GET or POST does not matter.
If you use HTTPS, then browser first establishes a secure connection with the host. Then the URL (also URL for GET request) is sent using this secure channel. It means nobody can read your URL even if you use GET request. It means, again no difference between GET and POST.
There are also other important aspects that @mike-ounsworth described, e.g. CSRF.
id/1part... Is that identifying a resource on your server, or the user? If it's identifying a resource, you most definitely want to leave it in the URL. If it's for the user, then you're much better off using a cookie. POST is generally for submitting forms, and you don't want your site's primary navigation method to be submitting forms the whole time.