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 your existing auth

Beyond the standalone endpoint, both legacy auth APIs accept an intent of variable along with the variable name. The value comes back inside the authentication response, after the credentials check has succeeded. Since this occurs while the app is authenticating, fetching a variable this way adds no extra round trip, and the value reaches only users who passed the same checks that grant access to your program.

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 System Locker C++20 library exposes variables as a first-class part of the client, so you do not hand-write the request. Construct a syslocker::Client with your system ID and read values through variables().get(). Each call returns a Result that reports whether the variable was found and carries its value.

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

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

    // A protected value, readable only with a valid license key.
    auto apiSecret = client.variables().get("API_SECRET", "YOUR_LICENSE_KEY");
    if (apiSecret.ok() && apiSecret->intent) {
        std::cout << apiSecret->value << '\n';
    }

    // A value that is safe for anyone with the system ID.
    auto announcement = client.variables().get("ANNOUNCEMENT");
    if (announcement.ok() && announcement->intent) {
        std::cout << announcement->value << '\n';
    }
}

Pass the license key as the second argument to read protected variables; the library sends it with the request and the server runs the same validity check. The library owns the HTTPS connection, TLS validation, form encoding, and response parsing, so this stays a few lines long. Variables are available before and after authentication, and the same Variables object is part of the client from construction.

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