DEV Community: Aharon Hyman

Beyond the Vibe: Why “Secure by Default” is the Only Way to Build in 2026

Aharon Hyman — Mon, 11 May 2026 07:39:11 +0000

Beyond the Vibe: Why "Secure by Default" is the Only Way to Build in 2026

We’ve all been there. You’re trying to complete a simple task—in my case, registering my son for a Judo seminar—and the page hangs. As a developer, your instinct isn't to refresh; it's to open the Network Tab.

What I found wasn't just a bug. It was a window into a growing problem in the era of "vibe coding" and rapid-fire deployment.

The Discovery: A Judo Chop to Data Privacy

The landing page for this event was built using a popular third-party "vibe coding" platform. These tools are incredible for speed, allowing users to describe a functional app and see it come to life in seconds. However, speed without a safety net is a liability.

By inspecting the network traffic to see why the registration was failing, I realized the API wasn't just sending my son's data—it was capable of sending everyone's. Using Postman, I confirmed the worst: I had full CRUD (Create, Read, Update, Delete) access. I could have wiped the entire event roster or modified participant details with a few clicks.

The Root Cause: The Danger of Permissive Defaults

The platform offered a simple toggle: [Allow All Users] vs. [Admins Only]. By default, it was set to "Allow All Users." This is the "Default-Allow" trap. It assumes the developer will remember to lock the doors later. But if a door starts unlocked, it usually stays unlocked.

How Sticklight Handles This

Short answer: Sticklight defaults to "Deny All" by design.

Seeing this failure in the wild made me reflect on our own architecture. Here is the breakdown of how we prevent this exact scenario:

Row Level Security (RLS) is Mandatory

When Cloud Backend is enabled in Sticklight, every table has RLS enabled by default. With RLS enabled and no policies defined, the default behavior is a total lockdown:

SELECT/INSERT/UPDATE/DELETE: All Denied.

This is the polar opposite of the "Allow All Users" default. In Sticklight, if a developer forgets to add policies, users get a 403 error—not access to the entire database.

Policies Must Be Explicitly Created

The AI agent is built with a security-first mindset. It is instructed to:

Never disable RLS.
Never create USING (true) policies unless data is genuinely public.
Always scope user data with user_id filters.
Create the minimum necessary permissions.

Example: The Judo Registration Table

If this seminar page had been built in Sticklight, the generated SQL would look like this:

-- RLS is enabled by default. -- Policy: Users can only see their OWN registration. CREATE POLICY "Users can view own registration" ON registrations FOR SELECT USING (user_id = auth.uid());

In this scenario, an attacker inspecting the network tab would only see their own data. The "vibe" remains the same for the user, but the data remains private.

The Failure Mode Comparison

Scenario	Other "Vibe" Platforms	Sticklight
Default setting	"All Users" (permissive)	No access (deny all)
Forgot to configure	Full CRUD for everyone	403 Forbidden
Failure mode	Silent data breach	Broken feature (visible)

Pro-Tip: How to "Vibe Code" Without Leaking Data

If you’re building your own apps from scratch using AI agents (like Claude Code, Replit Agent, or Cursor), you are the primary architect. Here’s how to ensure your vibe stays secure:

Use Security-First Prompting: Specifically instruct the AI to use Secure-by-Default patterns and assume the frontend is untrusted.
Establish a Security Rubric: Maintain a persistent CLAUDE.md or instructions file that mandates RLS and 403-by-default behavior.
The "Postman Audit": Never trust the UI. Manually test your API endpoints with tools like Postman to ensure they don't leak data when unauthenticated.
Review Every Diff: Look specifically for cases where the agent might have simplified a policy or left a "TODO" on an authentication check.

Conclusion

As we move toward AI-generated boilerplate and "vibe-driven" development, the responsibility shifts to the platform architect. At Sticklight, we believe a "broken" feature is a ticket, but a "broken" security setting is a catastrophic liability. By choosing a "Deny All" default, we ensure that the path of least resistance for a developer is also the safest one for the end user.

CodeSandbox init shortcuts

Aharon Hyman — Wed, 06 Jan 2021 12:52:44 +0000

Fun new find of the day
Type into browser URL: “http://js.new”, “http://vue.new”, “http://react.new”, “http://ng.new”, “http://ts.new”
You will get full environment to play around in.

Imposter syndrome & at what point did you realise you where a developer

Aharon Hyman — Sun, 29 Nov 2020 19:59:38 +0000

Imposter syndrome is something I have often felt in my journey to becoming a developer.
I am self taught (mostly), and was lucky to be given a chance at a growing start up (Strattic).
My first few weeks where filled with fake it until you make it, with many late nights and LOOOOTS of caffeine. But I after a couple of weeks I sat down with the team to show what I had achieved and I amazed myself.
I look back on that code now and laugh, and am amazed that not only does it still work but some of that code still on production (with a lot of refactors and help from much more experienced devs).
Did you have an AH HA! moment when you suddenly realised you where keeping up with the big boys?

Maintaining a company culture while working from home?

Aharon Hyman — Sun, 15 Nov 2020 11:54:29 +0000

Company culture at home.

Has your company switched to remote work?
Have you made any changes to your company culture to fit in with a remote environment?
Do you find your life-work balance has shifted as a result of remote work?

I will start :D.
Our company values our work culture and has spent time supporting us whether with assistance to set up a home office or with increased social interactions 'online'.
We moved out weekly happy hour online and try to spend some time catching up with each other outside of our regular meetings.
A big one for me was encouraging everyone to have their videos on during meetings, it helps you feel like you are talking with colleagues and humans, not just talking to a computer. Even if it means you have to get more formal looking PJ's!
Being at home especially during lockdown has meant that putting in a full work day can sometimes not be so easy, especially with little kids around. Work being flexible and allowing for make up hours in the evenings is a big help.

Why I will no longer be using console.log() to check React state updates

Aharon Hyman — Wed, 11 Nov 2020 09:05:15 +0000

As a front end developer one of the key tools in my debugging arsenal is the console log. The ability to log data and check that it renders as expected in the browser allows you to quickly debug specific parts of your code in a quick and neat fashion.

I work in React and being able to console log your state and check that the components are rendering as expected is a key development pattern.

When your state is simple and you have one or two values to monitor, console.log() is great but when you start adding more to your component state especially in a Class component this can start getting very ugly as your state object being output is minified.

Console.table()

Console.table is a great way of logging to the console that will parse your data and log in the console as a table.

Using the console in Chrome dev tools we can see console.table() at work

The function console.table() takes either an array or an object and can also take an optional parameter ‘columns’

The first column will be labelled index and in the case of an array it will display the indices, while an object will display the Key or property names.

The table also works as you would expect allowing you to sort the column by clicking on the title.

Note that in Firefox console.table() is currently limited to 1000 rows

Columns
Where this really comes in useful is the columns parameter.
As a default the columns.table() will list all the elements in an object. The columns parameter takes an array of column names or values and allows you to select the values you would like displayed. By using this you are able to parse an array of large objects and select only the columns relevant to you.

Logging your state!
Going back to React, a common pattern is to store a server response in your state, often there is data involved that will not be used in the component you are working on.
Using the columns parameter you can display in the console only the columns of data that you are actually watching

Lets see what that looks like
In the below example our api call returns a json of users and they are stored in the state.
Using console.table(users) in the render we will be able to produce the below table and check the data is as expected, without having to build out our table component in the ui.

Now if we wanted to build a quick filter button to check which of our clients paid in Yuan Renminbi we could do the following



const onlyYuanUsers = users.filter( user => user.currency === "Yuan Renminbi")
console.table(onlyYuanUsers)

this will produce a filtered table to check it returns the values you need.

But this is more data than you need to display to check your filter is working.

By passing in the columns parameter, you are able to select which columns you want to select by defining an array of the column names.

The output will be a more compact table allowing for an ‘at a glance’ comparison.



console.table(onlyYuanUsers, ['id', 'currency'])

It is worthy of note that as of publishing console.table() is supported by all modern browsers with the exception of IE (I did say modern)