Continuing in our series in breaking down application security so that anyone can do it without hiring expensive teams of employees, we talk about the more nuanced last part of securing the perimeter: authorization aka proper ownership.

Last time we discussed my framework of an application’s perimeter security: GTFO.

We discussed how we need to start off with blocking off all access to any open entrypoints (any routes/endpoints of an application), ensuring everyone is tracked by funneling everyone through a centralized chokepoint (guards aka security middleware), everyone is identified and ensured a guest as they go through the chokepoint.

I’ve separated out the last part of GTFO which is ownership because it is nuanced and ties back to a concept we discussed before: Application Context.

Ownership

So what is ownership? Ownershipis the state of owningsomething (circular, yes). If we define owning something, it merely means to have or hold as property.

Continuing our example of your home, you own the entirety of your home! So no one should be able to fight against that fact. Because you own the home, you have every permission to do whatever you want with and to the home, however, no one else has the same permissions as you do. It’d be strange if you couldn’t do whatever you wanted with your home.

By proxy, your family members may have similar permissions, but you may limit (or they may limit themselves) from doing whatever they wish because they don’t have the full ownership like you do. The permissions are similar, but not the same.

Your best friends may come over, but once again the set of things they have access to do with/at/to your home is even more removed than your family members because they are further away from ownership than your family members. The further people are removed from you, the less permissions they have.

The question is…

With every home, owner, family, friend and stranger, there are extremely nuanced set of permissions everyone gets. But why..? Couldn’t we apply the same rules of one set of permissions of a home to any other’s? No! This is because every person/home is different and we need to have careful understanding of boundaries that have to be set.

Let’s take for example that in your home you have a refrigerator that you have placed out in the open so that any guest can rummage through and grab a drink or snack or whatever they want, no questions asked, because you have provided that to any person welcome to your home as an amenity. You’re very gracious!

If you took that same set of rules/mentality and went to a neighbor’s home who had a refrigerator out in the open, and you rummaged within their refrigerator, it’s a 50/50 chance that they’d scoff at your rudeness and ask you to leave.

So really.. the question is.. why? Why can’t they be gracious? Why do they have to be different? It’s simply because every home and person is different and understanding them more is not only appropriate, it’s required as a social norm. Bonus Social tip: It’s polite to always ask before you take action, and even though it’s not required… it’s kind of required.

In the same way, every application is different. Every application will have different customers with different data that they own. If you are an admin on your own platform, you might have access to the whole kingdom, but if someone is not an admin they should not have that sort of access. They would have to have a subset of that access.

The set of permissions that each individual or group gets is syntactic by nature. This is the easy stuff because you’re just creating the rules that are well defined and the rules govern what every person or group of people can/can’t do within your application/home. For example, “Guests can open refrigerator” makes sense, but “Refrigerator can open guests” probably won’t?

However, who should actually receive those specific sets of permissions is semantic by nature, meaning it is driven by context, relationship, and real-world logic. Only you would know who your family members and friends are and knowing which set of permissions they get. You are the only person with that knowledge. A neighbor wouldn’t get the permission of being able to use your bathroom without asking like your mother would. That just wouldn’t make sense to you because 1. they have their own home nearby 2. they were never invited to do such a thing. This is why understanding your application (application context) is so important.

Only you as the application developer/owner would have the context to understand who should be able to do what in your application/business. No knock to AI coding agents, but they just don’t have the full picture like you do. They’ll mess it up if you allow them to. It’s important to check their work!

So how do I do this?

We discussed locking all your endpoint/routes down, then passing all requests through a middleware to ensure that everyone is authenticated/identified.

The important part now is to, on a per route basis, assess which ones touch any data at all. Data is always owned by someone, whether it’s you/your system generating it, another human, or an AI agent. In a CRUDsystem, you have to make sure no one else is touching another individual’s data, whether it’s just getting data or manipulating data (changing/deleting/creating).

This is the nuanced part:

1. Before doing anything with any data/resource, do a couple of checks:

   1. check who the person/requestor of resource is (this may not have been done at the middleware maybe? so ensure you’ve identified who the person is)

   2. at this point, query or get the data with a proper attribution column (something to attach an ownership value to). If you have a properly maintained database, you should be able to tie back pieces of data back to who owns it. Check the value of who owns the piece of data against the user/requestor you just identified above. The values MUST match.

2. If, and only if, the individual/requestor has been identified AND the resource attribution/ownership has been validated that the identified individual/requestor owns that particular piece of data, then whatever business logic that you have (CRUD operations) can go through and be done. Otherwise return a 401 Unauthorized response and go about your day!

A ton of application security problems today stem not doing the above properly, but luckily for you, you’re not one of those companies that suffer from this issue and now have the secret to securing your perimeter!

Pigeon is a NYC Cybersecurity Services company, specializing in Application Security. If you or anyone you know needs application security services, please reach out to me at david@pigeonlabs.ai. We’re willing to work with you near and far!