Protect API

[enriweb77]

Hi everyone,
I would like to understand how I can protect my API so that they are only usable by frontend pages and external applications through a key.
At the moment I have seen that if I try to call my API from postman everything works without any type of authentication.

[kfawcett]

Always add Security Restrict to the top of your APIs. It’s annoying that this isn’t setup by default.

Please vote and comment on this feature request.

Make all APIs restricted by default

This request is to switch APIs from being unrestricted by default to restricted by default. If an API needs to be open then a “Security Unrestrict” could be added to the API. This is a better approach to ensure data is not leaked unintentionally by Wappler developers that miss the step or do not know better. This comes up every so often in posts and I would wager many Wapplers are exposing their data like this unsuspectingly.

TIP: Server Actions are not restricted by default

I didn’t realize this before. If you do not add the Security Restrct action to your Server Connects, then they are wide open for anyone to query. Add a Security Restrict at the top to keep them locked down. [image]

As for setting up API keys. There are multiple posts that discuss it. Unfortunately, there isn’t anything built into Wappler as this time, so you’ll have to design something yourself.

How to Create API-key Enabled Server Actions?

I appreciate your reply. You are seriously a rockstar! That’s not quite what I want to do. I want to be able to make a REST call by passing data on the headers instead of two separate calls - one to authenticate and one for my API. The article I referenced helped me figure it out but there wasn’t good Wappler documentation on how to get the HTTP header values. Here’s what I ended up doing: Followed the steps in this article to set up a User table Created 2 new server variables [image] …

Creating and providing external API with Wappler

This might be an approach for building a mechanism for API keys.

[enriweb77]

Thanks for the reply but I don’t know how to set this up, is there any example in the documentation?

[kfawcett]

For the first part of your request. You only need to add the Security Restrict to your APIs when you want to ensure the user has logged in to use/access them.

[enriweb77]

But I don’t have registered users, I just want my API to be protected by a key for example if it is consumed by an external app

[famousmag]

If there are no restriction and registered users then I suppose that this is a public api…
One thing you can do is to add first step inside your api to check if there is a key provided (and if you could check if that key is a ‘valid’ key it would be better)
So, if there is no valid key, don’t execute the api…

[enriweb77]

I can use my own key that I insert for example in the environment variables.
I want the APIs to be consumed only by the frontend pages or possibly by my external apps (For example I’m doing an integration with make between linkedin and my lead collection API).
If someone finds an unprotected API they could make endless calls and bring down my server, right?

[famousmag]

I’m not the experienced guy here but… I think you should just calm down my friend.
If no sensitive info are behind this api you just check for the presence of a valid key. Let them CALL the api but unless a valid api key is provided not execute it.
I haven’t asked what kind of api you’re making there out of privacy but… is it worth this much protection?

[Cheese]

Could employ rate limiting using Cloudflare (available on the free plan) to the path for the requested API and also use Server Connect routing to shield its origin. Be sure to set the correct response for authorised requests and unauthorised alike using a Condition within the Action accordingly.

[Digo]

I think you might be a bit confused around how the server actions work.

In very simple terms, APIs (Server Actions) in Wappler are what lets you pull back end data to the front end (among other things). If you want users to see some kind of dynamic data, you’ll probably need to use them.

From what you are describing, an API key wouldn’t be useful, because you’d be effectively removing the ability for someone to go to your site and load the dynamic data on the front end.

Someone refreshing really isn’t an issue. It’s just like if you were to keep refreshing any site. If someone tried hard enough, they could take down any site. But what you’d more likely have an issue with is API rate limits from linkedin or wherever you are pulling your data from.

Without know what you are exactly trying to build, it’s hard to advise, but take for instance you wanted to display your LinkedIn posts on your Wappler created site. One method would be:

• Have a server action that pulls this data from linkedin using the API action, and is set to display the output that you can then display on the front end.

However, there’s probably rate limits on linkedin, so if someone were to constantly refresh an action, you’d be constantly pinging the linkedin API to fetch said data which might get you rate limited.

To get around this, you could either implement caching:, or, do it another way:

• Have a schedule action that runs every X amount of minutes (depending on api rate limits) and saves the data to a database. You would then set your server connect action to pull the data from the database instead of directly from linkedin, which would resolve the issue of hitting your rate limit.

[HeikoK]

@famousmag

I’m not the experienced guy here but… I think you should just calm down my friend.
If no sensitive info are behind this api you just check for the presence of a valid key. Let them CALL the api but unless a valid api key is provided not execute it.
I haven’t asked what kind of api you’re making there out of privacy but… is it worth this much protection?

This pretty much sums it up and gives a solution for publicly exposed API that is not secured by user authentication.

If a key (header, a hidden form) is not enough, use also a less public domain name (like SupaBase does) and restrict the IP’s that can access the server.