I would like to raise a security concern regarding the current Bricks licensing system, especially for freelancers and agencies. The problem is not about someone activating an extra site here and there, but that the master license key tied to my account ends up on client websites. I can legitimately build a site, activate Bricks, and hand it over to the client. A couple of years later, another developer or potential attacker gets full access to that site and extracts my key. Whitelisting does not solve this: it blocks activation on unauthorized domains, but does not prevent the master key itself from being exposed. It seems to me that the solution must come from the licensing model itself. For example, generating a unique, site-specific key or token for each website, without distributing the main account key across dozens of sites.
My question is: is the Bricks team considering a move toward site-specific keys or another mechanism that does not expose the master key?
Yes, it would be great to add a feature that generates a subkey for the client’s website. It would be similar to the Crocoblock website licence feature, it would be perfect !
Yes that is my concern too, that would be a solution. But maybe an idea could be to register the site in the dashboard and check with bricks if the license is valid. You can revoke a site from the bricks dashboard.
The people at webfactory (wpreset, wpcaptcha) have a great solution for this.
Whitelisting could be a way to go. But i do not want to have to add the key inside of bricks.
I hope they build something inside of bricks for this.
How is it accessible? It is masked within the admin screen (and masked even if you inspect in devtools).
Do you mean if someone went into the db itself to extract the key value? I guess that may expose the full key (I haven’t personally checked to see if it gets hashed or not), but even in a case like that, you can always login to your Bricks account and remove a site that doesn’t belong.
It is stored in the database, in the wp_options table. Or you can simply search for bricks_license_key. And it is not hashed — this has been confirmed by many users.
Again, I know about blacklists and whitelists, but when you work in a team, using these lists is not always very convenient.
Here is an example situation: you build a website, hand it over to the client, and part ways. Some time later, another “unscrupulous” developer gets your key from that website and publishes it, for example, on Reddit. Then you receive an email from the Bricks team regarding a violation of the license key sharing rules…
Would you really want to spend your time proving afterwards that you did nothing wrong? Would you be able to sleep peacefully knowing that the license key you paid for is not protected in any meaningful way? These are rhetorical questions 
So, the point of my post is that there is a real need to change the licensing system and make the process more secure by using a separate key for each website.
Or you could just make every client buy their own license.
solution would be making the domain based license assignment better.
instead of everytime adding license key to a every bricks install what we can do (optional) is;
we can add/assign license to a domain from the bricksbuilder.io panel and that domain will not have to have a license key on db but only valid license assigned from the remote bricks panel.
this way we dont have to save our key to every website db and makes the license management more controlable/managable as well.
i think this is the solution to implement.
it solves multiple issues including key security.
I’m also very interested in this issue and have been concerned about it for several months.
What worries me even more is that I discovered that the Bricks license key is stored directly in the website’s MySQL database in plain text, without any encryption or other meaningful protection. Anyone who gains sufficient access to the website or its database can simply retrieve the license key.
For freelancers and agencies managing dozens of client websites, this means the same master license key associated with our Bricks account is effectively being distributed across all of those installations. Even if domain whitelisting prevents unauthorized activation, it does not protect the key itself from being extracted and exposed.
In my opinion, this really needs to be addressed at the licensing architecture level. Site-specific keys, installation tokens, or some other revocable per-site credential would be a much safer approach than storing the account’s master license key on every client website.
I would also like to know whether the Bricks team has any plans to change this system.
This is a very valid concern. Anybody who has access to the database, could easily retrieve the key. Its there in plain text. I have checked it myself.
Its not practical to check the Bricks account profile frequently to blacklist any suspicious sites when we have more than a few client websites. Bricks team should take action on this to encrypt the key and store in the databse, so that it will be difficult to retrieve it when the site is handled by somebody else after some years.