One of the biggest projects developed by our team is a groupware platform. What makes it unique is that we wrote only the frontend. Every part of the backend, from data storage to authentication, is handled by our own system: Skapi.
That’s what one of our frontend engineers tell:
“Security isn’t always something you can see right away. It doesn't feel tangible at first. But as I worked through different features and use cases, I had to carefully design data structures to fit specific needs. That’s when it started to click. I could see that the data was being received exactly as expected, and more importantly, access was being correctly restricted when it needed to be. That’s when I knew the system was working as it should.”
In this article, we’ll walk you through how we implement security directly from the frontend using Skapi for backend. This isn’t theory, we’re sharing what we’ve learned from real projects we did ourselves.
How to Implement Security from the Frontend
1. How we handle data restrictions
Traditionally, frontend security is an afterthought. But with Skapi, security is baked into the process right from the start. As front-end developers, we think from the user’s perspective: Who should be able to view, edit, or share this data? Instead of writing complex server code to enforce that logic, we configure it directly when we create or update data on the frontend.
This approach has allowed us to avoid major security issues altogether. When problems do arise, they’re usually related to poorly structured data – something that’s easy to fix without touching backend logic.
For example, when uploading data to Skapi, you’re required to define the access level directly from the frontend. This gives you full control over who can read or modify the data.
In the example below, we're uploading data with the access group set to "private". This means only the uploader will be able to read the data:
skapi.postRecord(
{ data: "my private data" },
{
table: {
name: "NobodyCanSeeThis",
access_group: "private"
}
}
);
This is just a simple case, but Skapi allows for much more advanced access control, letting you restrict data visibility to specific users, roles, or even dynamically set permissions depending on the context.
Here’s how you can easily restrict data visibility securely from the frontend:
skapi.grantPrivateRecordAccess({
record_id: 'record_id_of_the_private_record',
user_id: 'user_id_to_grant_access'
})
We use this feature in our groupware project when attaching reference documents, ensuring that only authorized users can see them. Unauthorized users simply hit a permission wall.
2. How we handle secret keys for 3rd APIs
When working with third-party APIs, one of the most important rules is: never expose your secret key. And that is one of the reasons you’ll need to deploy an idle backend server just to act as a secure middle layer for those API requests. But keeping a server running 24/7 can get expensive and adds unnecessary complexity.
With Skapi, there’s a smarter way. In Skapi platform you can save only the secret key from the service dashboard and let Skapi make a request to 3rd party APIs without ever exposing those keys in your frontend code:
const data = await skapi.clientSecretRequest({
clientSecretName: 'ggltoken',
url: tokenUrl,
method: 'POST',
headers: {
'Content-Type': 'application/json'
},
data: params
});
This is an example of how Skapi makes a request to the Google OAuth API using the secret key saved in our dashboard under the name “ggltoken.” Without exposing the actual secret keys, Skapi safely returns the data to the client.
3. How we handle data authentication
Behind the scenes, all the authorization is managed by Skapi. Authorization for data access, 3rd party API requests, etc. can be easily defined without deploying any backend servers. Skapi uses JWT-based authentication and provides solid security with various verification systems. All the token handling logic is taken care of by Skapi’s frontend JavaScript library. No more struggling with various edge cases – Skapi just nails it and gets it running.
When it comes to security on the frontend, there aren’t many areas that require heavy lifting. In most cases, it's about setting the right access permissions when creating or updating data. Beyond that, you don't need to worry much – Skapi already handles the deeper security implementation on the backend.
4. How we prevent threats like XSS and CSRF
Preventing threats like XSS and CSRF is largely out of the front-end's hands these days, thanks to modern browser security improvements. These vulnerabilities have become less of a concern, especially when combined with platform-level protections. Skapi also reinforces this by allowing developers to restrict API usage to specific URLs via CORS settings in the dashboard, adding another layer of defense.
This simple yet powerful setup allows frontend developers to maintain secure communication with the backend without allowing requests from suspicious users.
How We Verify That Data Is Truly Protected
One clear example of how we verify data protection, comes from our groupware project, specifically within the electronic approval system. When users attach reference documents, the system enforces access restrictions based on the initial permission settings. As a result, unauthorized third parties are automatically blocked from viewing the documents, confirming that the authorization logic is working exactly as intended.
This demonstrates how access is governed entirely by the permissions configured at the time of data creation. Users can view or delete data only if they have the appropriate rights, and only the data owner is allowed to edit it. Additionally, users can retrieve a list of others who have been granted access, ensuring transparency and control. Anyone without explicit permission simply cannot access the data.
This level of control not only reinforces security but also gives users confidence that their data is safe and only visible to those they want.
Why This Approach Works for Us
From our experience, we’ve never encountered a security failure on the frontend itself. The only issues we’ve seen were related to incorrectly designed data structures, problems that are easy to avoid with a bit of planning. In fact, we believe most frontend-related security issues come down to structure, not system flaws. When permissions and access rules are clearly defined, everything just works.
Importantly, we’ve never had to sacrifice usability for the sake of security or vice versa. We believe security should never be compromised to improve user experience. Instead, thoughtful data structure design allows both to coexist. By aligning your structure with real-world use cases, you can create applications that are both secure and intuitive.
Another major advantage of this approach is speed. With Skapi, setting up the backend requires almost no configuration. In most cases, you’re ready to go with a few lines of code. This drastically reduces development time and lets frontend developers build full-stack applications without waiting on backend infrastructure.
And the best part? You don’t need any special backend skills. If you know JavaScript, you’re ready to go. Having a basic understanding of how to design data structures helps, but there’s no need to learn server architecture or cryptography. Skapi’s documentation is written in TypeScript, so being comfortable reading TypeScript is a plus, but not a requirement.
Final Thoughts
Everything we shared in this article comes directly from our own projects, especially our groupware system built entirely with a frontend-first mindset and Skapi powering the backend. What started as an internal tool has become the core of everything we build.
If you’re a frontend developer looking to build full-stack applications without the usual backend hassle, we highly recommend giving Skapi a try. It simplifies development without compromising on performance or security.
Check out our other posts where we cover practical use cases and real-world solutions using @skapi_api .
Follow us on X, LinkedIn, or wherever you hang out – we're always sharing new ideas and dev-friendly updates.
Thanks for reading, and if you found this helpful, drop a like or leave a comment!
Top comments (0)
Some comments may only be visible to logged-in visitors. Sign in to view all comments.