OSPRY Pixel Security: The Boring Stuff That Matters

A prospect asked one of our team whether putting the OSPRY pixel on their website meant Chinese hackers could get in.

Fair question. Ask it about every script on your site.

Before I could type my answer, she had already sent hers:

"Mario is more likely to hack China than be hacked by China."

I'm not even mad. She knows who builds this.

The prospect still deserved a proper answer. If you are putting someone else's code on your website, you should understand what you are installing, what access it needs, and who takes responsibility for it.

Here is the boring version, for the people who actually read.

What installing the pixel gives us access to

The OSPRY pixel runs in your visitors' browsers, like an analytics tag. Installing it does not require you to give OSPRY your server login, hosting password, website administrator credentials or database connection.

You are adding browser-side code. You are not handing us the keys to your backend.

That distinction matters. It also deserves an honest explanation: JavaScript running on a page has access to parts of that page and the capabilities the browser permits. Third-party scripts are a real security consideration. Calling something a pixel does not make it harmless, and a script does not become safe because it came with a friendly logo.

The useful question is what that particular script does, what information it reads, where it sends that information, and how the company behind it controls changes.

For OSPRY, the installation is a browser integration. A separate CRM or other connected service has its own access and authorization requirements. Adding the pixel does not automatically grant those permissions. Review the integrations you choose to connect as separate decisions.

Where the script comes from, and where it is meant to run

The pixel loads through Cloudflare's edge from our domain. It is configured to activate on the website domains you approve.

That gives the installation a defined source and a defined deployment boundary. You should know which domain is delivering a script and which of your properties are authorized to use it. An unidentified snippet copied from an old email is a poor foundation for a production website.

Domain approval is one control within the system. It is not a substitute for protecting the code-delivery path, reviewing changes or controlling administrative access. A list of approved domains should never be presented as proof that every possible request is trustworthy.

Cloudflare provides a global delivery network. Its role in delivering the script should also be kept separate from the permissions of the script after your visitor's browser loads it. Delivery, execution and data processing are different parts of the explanation.

We should be able to discuss all three clearly.

Who is behind OSPRY

Legion Code Inc. is an American company.

We choose our infrastructure from American, European and Australian providers. The AI models we use come from American and Canadian providers.

Those are deliberate supplier choices. They tell you something about the companies and jurisdictions involved in operating the product. They do not, by themselves, explain where every network request travels or establish a particular data-residency commitment.

Cloudflare's edge is global. The country in which a supplier is based and the location in which a particular service processes data are separate facts. If your organization has regional processing requirements, bring those requirements into the conversation so we can discuss the relevant services and data flows specifically.

We are happy to explain who we work with. We are also going to be precise about what that answer means.

A company's address is useful information. How it operates is what deserves the next set of questions.

Security review is daily work

Our security process includes daily human and AI-assisted review. We also pay outside penetration testers to challenge the system.

That is useful because the person who built something should not be the only person looking for ways it could fail. Automated analysis can cover repetitive checks. Human reviewers can question assumptions, examine context and challenge a design. Outside testers bring another perspective to the places we might have become too comfortable with.

We are not aware of a successful compromise of OSPRY through those testing engagements.

That is a statement about the results we know, not a prediction about every attack someone might attempt tomorrow. Testing has a scope. A clean result in one engagement does not establish that an entire platform is permanently immune to attack.

A security issue can matter long before it becomes a breach. That is why the work continues after a test finishes, and why security review belongs in the normal development process.

Access is protected, and services have boundaries

Human administrative access across our infrastructure is protected with MFA. Services and databases are isolated.

Those controls address different problems. MFA adds protection around a human account. Service and database boundaries limit how much access a component should have. Neither makes the other unnecessary.

An application should not need unrestricted access to every database because one feature needs one record. A routine operational task should not require the same authority as administering the whole environment. Those are the kinds of boundaries worth maintaining as a product grows.

MFA for people also does not remove the need to protect application credentials and service access. Software still needs ways to communicate. Those permissions deserve their own controls rather than being waved away with an MFA checkbox.

We would rather explain the boundaries than hide behind a claim that we take security seriously. Every vendor says that. The useful conversation is about what access exists, why it exists and how it is controlled.

No code ships without my sign-off

Our human team remains accountable for what we ship. No code goes out without their sign-off.

That does not mean a person can spot every defect. It means there is human ownership at the release boundary who is responsible for the decision to put a change in front of customers.

AI can help us write, inspect and challenge code. It does not remove that responsibility. An automated check passing is one piece of evidence. A human still has to decide whether the change is ready to leave the building.

The same principle applies to the broader OSPRY product: the person using a tool should be able to understand its purpose, and someone building it should remain accountable for its behavior.

Security and privacy belong in the same conversation

Protecting access is only part of responsible operation. You should also understand what data a tool collects and what choices govern collection. Our privacy and processing terms belong in that review.

Before installing a script, establish what it needs to observe for the job you want it to do. Check which page elements or events are involved, which services receive information, and what your consent configuration permits.

Review the OSPRY consent controls alongside the installation. A security explanation should not become an excuse to skip the data-collection conversation.

If you are deploying across several client sites, make those questions part of each client's setup. Approval for one domain or one integration should not quietly become a blanket assumption about every other property the agency manages.

Ask the uncomfortable questions before you paste the script

Here are the questions we would want answered by any vendor, including us:

• What credentials do you actually need from my business?
• What does the browser script read, and where does it send that information?
• Which domains and connected services have I authorized?
• How is access to the infrastructure protected?
• Who reviews changes, and who is accountable for a release?
• What does security testing cover, and what happens after it finds an issue?
• How can I stop collection or disconnect an integration when I no longer need it?

Ask for a plain answer. You should not need to translate a sales pitch into a security architecture.

If your team has a vendor questionnaire or a particular installation concern, bring it to us. Tell us what your site does, what you want to connect and which requirements you need explained.

The nationality of an attacker does not change the standard we should hold ourselves to. Negligence creates openings: forgotten accounts, excessive permissions, careless releases and assumptions nobody checks.

We work on those details every day.

The joke was good. The boring work is the point.