How to protect your program's sensitive data with Server Side Variables

When you compile and ship an application, every string you embed in the binary is available to anyone who inspects it. API keys, webhook URLs, and backend addresses can be recovered with nothing more than a strings search or a debugger. Once a secret has shipped to customers, you have to assume everyone has access to it.

Server Side Variables in System Locker are named values stored on our servers instead of inside your program. Your application requests the ones it needs over HTTPS, and you can edit them at any time from the developer dashboard. Every installed copy sees the new value on its next read. That keeps sensitive data out of the distributed file and gives you a remote control for the values your software depends on.

1. Secrets don't belong in the binary

Client software is untrusted by definition. It runs on hardware you do not control, and the person running it can read and modify it. Anything your binary contains can be extracted, and anything it can decrypt can be decrypted by an attacker. Therefore, any file you distribute should be considered public material. A server-side variable is a safer alternative: the value exists in a single location, is served over an HTTPS connection, and is never bundled with the app.

2. How Server Side Variables work

Each variable belongs to one system and has a name and a value. Names are unique within a system, so a single variable per system is all you need. You create and edit them on the Variables page of the developer dashboard, and new variables are protected by default.

Reading a variable is a single HTTPS POST to /auth/variable. The request needs your system ID, the variable name, and a license key when the variable is protected.

POST https://systemlocker.net/auth/variable

system=YOUR_SYSTEM_ID
variable=API_SECRET
key=YOUR_LICENSE_KEY

If the variable exists and the key is valid, the response looks like this:

{"intent":true,"var_API_SECRET":"server-side value"}

Add clean=1 to receive the bare value instead of the JSON wrapper. If the variable does not exist, the response is {"intent":false}.

3. Protect the values that matter

The values you want to hide go into protected variables, and that is the default for anything you create. A protected variable is returned only when the request carries a valid license key for the system. The check runs server-side: the key must exist, must have been redeemed, must not be frozen, and must not have expired.

When the key is missing or invalid, the server answers exactly as it does for a variable that does not exist. An attacker cannot tell a protected variable apart from a missing one, because the response is identical. The value stays in memory after being retrieved by a real user. Revoke or expire the key, and that key loses the ability to read the value even though the same application is still installed.

4. Unauthenticated variables: great for URLs, webhooks, and live settings

The obvious use for variables is protecting secrets, but variables earn their keep for anything you want to change without shipping a build:

• A Discord or Slack webhook URL your app reports events to.
• The download or update-check address for your product.
• A support or help-center link you might need to redirect later.
• Short maintenance or announcement text shown at startup.
• Feature flags and default settings you want to tune after release.

Each is a value your program reads from the server instead of embedding. Change one in the dashboard, and every running copy picks it up on the next read. No recompile, no patch, no message telling customers to redownload.

5. Read through the API that matches your deployment

For a trusted central service, the Simple API's variable endpoint is a direct way to read a value after a key check. For software running on customer hardware, Bedrock can request variables during signed initialization or a heartbeat, so the value arrives inside the same verified response as the live authorization.

Protected and unprotected variables cover the common shapes: unauthenticated reads for public values, and either a key or a successful login for protected ones. You can configure this individually for each variable in the dashboard.

6. The C++ library has this built in

The Bedrock C++ reference client exposes requested variables in its signed authentication result, so you do not hand-write the response validation. Ask for the names during initialization and read them only after the session has started.

#include <syslocker/bedrock.hpp>
#include <iostream>

int main()
{
    syslocker::bedrock::Config cfg;
    cfg.systemId = "YOUR_SYSTEM_ID";
    cfg.signingPublicKey = "YOUR_BASE64URL_RAW_ED25519_PUBLIC_KEY";
    syslocker::bedrock::Client client(cfg);

    syslocker::bedrock::InitializationOptions options;
    options.variables = {"API_SECRET", "ANNOUNCEMENT"};
    auto auth = client.authenticateWithKey("YOUR_LICENSE_KEY", options);
    if (!auth || !auth->sessionStarted) {
        return 1;
    }

    const auto& values = auth->response.variables;
    if (auto it = values.find("API_SECRET"); it != values.end() && it->second)
        std::cout << *it->second << '\n';
    if (auto it = values.find("ANNOUNCEMENT"); it != values.end() && it->second)
        std::cout << *it->second << '\n';
}

Bedrock verifies the response before exposing the variables map. A missing variable is represented as false; do not treat a missing value as authorization. Keep truly dangerous material on a backend you control even when a protected variable keeps it out of the distributed binary.

7. Plan limits

Variables are just another layer to add to your defenses. A protected value still ends up in the client's memory, so an attacker with a valid key could capture it at runtime. Keep genuinely dangerous material on the server or in a private backend you control, and never ship it to clients. Variables keep sensitive values out of the distributed file and let you rotate or change them centrally, thus raising the bar—but they do not make a value impossible to read sensitive information.

All plans include server-side variables. The free plan allows 5 per system, and paid plans scale up to 200 per system. This is plenty for most use cases, but you can always upgrade if you need more. Upgrades are seamless and pro-rated, meaning you only pay for the difference between your current plan and your new plan.

Ready to keep secrets out of your next build?

Variables are easy to set up in the dashboard, and they're easy to integrate — the official C++ library fully supports them.

Get Basic for $2/month Open C++ library on GitHub