I think it is worth taking the time to ask why you are using an origin and referrer check to enable your CSRF validation.
To answer your actual question though, the answer is that no, you can't do anything to allow user's to type the URL directly into the browser and still gain access to whatever resource/action your CSRF setup is protecting. Except by using cookies, there is no way to distinguish between a user typing a URL in directly, and a malicious CSRF attack.
Edited to add more details:
The CSRF token I am describing is called a Synchronizer token on this page. The idea is that you pre-calculate a secret, store it in the user's session (which is why cookies are involved), include it in the form that will be submitted (but you don't place it in an actual cookie), and then verify that the CSRF token came up with the form and matches what you stored in the session. The reason it works is that the action is not allowed without the token, and the token is not given until the user actually visits the form to execute the action. For additional security you also regenerate the token for each form submission. As a result, a malicious user can't silently complete an action in the "background" because all actions can only be completed if the user first visits the page that contains the form and then submits the actual form.
The page you referenced in OWASP suggests using a dual security paradigm to protect against CSRF attacks:
- Verify Origin and Referrer headers
- Use a CSRF token
Proper application of defense-in-depth dictates taking all necessary security measures, which is why they suggest using both methods to protect against CSRF. Sometimes though, reality requires a compromise, so it is worth mentioning all the pros and cons of either/both. Most importantly, when done properly, either method will protect you against all currently known CSRF attack vectors. Of course this is where defense in depth comes in, as having extra security (i.e. implementing both defense measures) potentially increases the chances of mitigating future attacks that have not yet been devised yet.
Despite this fact, every framework I have ever worked with uses only CSRF token protection out of the box (to the best of my knowledge). This includes Code Igniter, Laravel, Django, and Ruby on Rails. In the case of Django and Ruby on Rails I'm relying on their documentation to verify that fact (it is possible they left some details out), but for codeigniter and laravel I double checked the actual source code itself to make sure I wasn't mistaken. So in reality, it is common on the web to enable CSRF protection using only CSRF tokens. Whether or not that is a good idea for you depends on your comfort level of balancing security versus usability. However, it certainly isn't crazy to use only CSRF tokens to perform CSRF mitigation: many popular software systems do exactly that.
It occurs to me to ask one more question: why does your CSRF system prevent users from typing in an address? If a user simply types an address in their address bar to visit your page, that executes an HTTP/GET request, and GET requests shouldn't be subject to CSRF protection because the server should never take actions in response to a GET request. So in reality, there might also be an easier fix to your conundrum: make sure you never take actions in response to a GET request and then turn off CSRF protection on all GET requests. Then, user's will be able to type in URLs in a browser all they want.