I am creating a RESTful API that is decoupled from my frontend.
I only want my frontend to be able to access these endpoints. I am fearful someone else can create their own frontend and use my API.
Is this what you need?
Or maybe a practical solution?
Just to be clear, the “frontend” could be anyone.
Think of it as the client-side code you sent to your users browsers as being their own “server” on the user’s computer. This “server” makes async requests to your backend api. Your backend api has no way of knowing if this call is from a legit client or someone with their own front-end making their own calls, or someone evil trying to break in.
However this doesn’t mean you have no control over security, rather you can still protect your api using tons of methods (like the ones posted above). For example, you can use cookies+sessions to identify client browsers, so when they make a call to your api you know it was “them”, and give them access to their data. This is secure in the sense you give every client a “name-tag” to identify them, so I can’t show up asking for someone else’s data as I have my own name tag, or no name tag.
If you originally had in mind a setup where your front-end code is the only one able to make calls to your api you have 2 big issues.
- Your client-side code is shipped as-is to end users, so even if you add in “secret codes” or something there that allows it to gain special authorization to your api, they are all insecure as anyone can read/take them.
- Your client-side code can be ran from anywhere, so you can’t use IP based systems to prevent calls. Unless you know exactly who will be calling, for example if your app will only be used within a specific ip range on the local network (a computer in your room can call your site hosted in the closet for example).
Focus less so on how clients can access the api, and more on who the client is, and what permissions they have, and base your security around those aspects.
For example in a cookie+session setup, if a client copy-pastes their session keys and gives them to Dr. Evil, Dr.Evil can access their data via your API. Obviously no user would do this, but some security approach could be vulnerable to different attacks. Going back to the cookie+session approach, there are attacks like csrf where the browser (who manages the cookies) gets “tricked” into giving them to Dr.Evil basically.
Finally none of what I just talked about goes into application level security. Like admins can change stuff, but non-admins can’t. Your app might not have admins, but just users who can access only their data. All of these aspects are just as important as “high level” security that protects your api from malicious activities.
Security can get complex, and might seem scary, but there are tons of ways to protect and secure your applications (maybe to many haha) just start with learning one 
Goodluck!
PS. You might hear about JWT based authentication as being the easiest and most popular today, I personally agree it is the easiest but its also the easiest to screw up. If you end up storing JWT’s in localStorage, you basically put your keys to the kingdom into a cardboard box instead of a safe.
How about just implementing an simple API key?
Few of the best practices to secure your REST API:
- Filter input on arrival: Filter as narrowly as possible at the stage where user feedback is obtained, based on what is expected or true feedback.
- Use appropriate response headers: You may use the Content-Type and X-Content-Type-Options headers to prevent XSS in HTTP responses that are not meant to include any HTML or JavaScript, to ensure that browsers interpret the responses the way you want to.
- Use Content Security Policy: You may use the Content Protection Policy (CSP) as a last line of defence against attackers to decrease the severity of any XSS vulnerabilities that may exist. We can use the Node js xss-clean kit. This dependence prevents input users from adding HTML & Scripts.
- Logging and Monitoring: As per our requirement, we can choose the best resources, as well as specifying some policies such as data retention policy that involves how long backlogs will be maintained. Instrument activities for your API access to monitor key metrics and events. Keep the logs searchable and indexable.
- Give Limited Access: Each API can restrict access, with the API only able to perform the tasks they need to perform. With Role-Based Control, different API Keys read/write, OAuth Scopes, and authorization schemes, we can do this. This minimizes the probability that a sensitive field will be exposed accidentally.