Normal•4d ago

Illegal Usage of Other's App IDs

I was wondering how to prevent users from stealing other's app IDs and abusing them without hiding the ID completely. For example, you could create another unity project, and create a script that spams player models everywhere. Then, as long as you have the app ID, you could potentially spawn thousands of rigs everywhere, crashing anyone that is trying to play. Other things like this can be done using another's app ID. I want to do this on the free version.

kapa.ai•12/12/25, 6:02 AM

Hi @Orbit. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base.

kapa.ai•12/12/25, 6:03 AM

----------------------
Normcore’s free (hosted) service doesn’t expose all of the hard controls that Normcore Private has, but there are still a few important points and tools you can use.

What an app key actually protects

Normcore treats the app key as the namespace for your rooms; anyone who has that key can connect to rooms in that app and send valid Normcore traffic. [Ownership + lifetime] So you should assume: if the key is public, a malicious client can connect.

The security model is then:

Server validates the app key (rejects empty, disabled, paused, not found, etc.). [Disconnect events]
Once connected, ownership + lifetime flags are how you prevent arbitrary clients from modifying or persisting state. [Ownership + lifetime]

That means you can’t stop someone from connecting if they know your app key on the free service, but you can strongly limit what damage they can do.

Use ownership to restrict who can change objects

Only the owner of a model can change it; all children are protected by the parent’s ownership. [Ownership + lifetime]

For player rigs and any important objects:

Instantiate them owned by the local client:

[Destroy prefab on disconnect]

kapa.ai•12/12/25, 6:03 AM

On the root `RealtimeView` of your player and key prefabs, set `preventOwnershipTakeover = true` (via `Realtime.Instantiate` or prefab settings). This stops other clients from taking ownership and modifying them. [[Prevent takeover](<https://docs.normcore.io/room/ownership-and-lifetime-flags#prevent-ownership-takeover-of-a-realtimeview>)]
If you have custom `RealtimeComponent`s, compile their models with `createMetaModel: true` so they support per-component ownership. [[Component ownership](<https://docs.normcore.io/room/ownership-and-lifetime-flags#requesting-ownership-of-any-realtimecomponent-or-realtimemodel>)]

This doesn’t stop someone from spawning their own objects, but it prevents them from hijacking your players or game-critical models.

Use lifetime flags so junk doesn’t persist

Normcore can automatically remove models:

Mark “junk” / ephemeral prefabs with so they vanish when the owner disconnects. [Lifetime flags]
Only mark genuinely important shared objects as persistent (). [Lifetime flags]

This limits long‑term pollution of your rooms if someone joins and spams.

What additional controls require Normcore Private

The explicit “block or rate‑limit per user / per app / per room” functionality lives behind Normcore Private via webhooks and authoritative/server plugins:

kapa.ai•12/12/25, 6:03 AM

Webhooks let you decide whether a connection is allowed, based on , and a custom
```
context
```
```
context
```
string you send from your client. [Webhooks]
You can cache allow/deny decisions and even permanently reject certain contexts. [Webhook caching]
Authoritative servers / server plugins let you run Unity logic on the server with full control over the datastore (e.g., rejecting or deleting spammy objects). [Authoritative servers; Server plugins]

Those features are not available on the free hosted tier per the docs; they are documented only under Normcore Private.

What you cannot fully prevent on the free tier

Based on the docs, there’s no built‑in free‑tier mechanism to:

Hide the app key while still allowing third‑party “untrusted” clients to connect.
Rate‑limit object creation from the server side.
Globally ban a specific malicious client identity.

So with only the free tier, if someone really wants to connect with your app key and spam their own objects, the main mitigations you have are:

Make all critical game logic depend on owned models that only your actual client flow ever owns.
Use lifetime flags so spam doesn’t persist.
Design your client to ignore or cull remote objects that don’t match your expected schema or constraints (e.g., ignore remote models that aren’t children of a valid player root, or that exceed certain per-player counts). This is on the Unity side, not in the Normcore docs.

kapa.ai•12/12/25, 6:03 AM

If you need hard enforcement of per‑user limits or entitlement checks, the documented path is to move to Normcore Private and implement webhooks and/or server plugins as described above.
----------------------
Note: you can ask me a follow up question by @ mentioning me again

----------------------

kapa.ai•12/12/25, 6:03 AM

@1095079234759823521 Kapa.ai is still learning and improving, please let me know how I did by reacting below.

Mechabit•12/12/25, 6:21 AM

the app id is encrypted in builds

Alix Ollivier•12/12/25, 6:21 AM

I had this same issue! It was a hacker named Lyntrex, was he hacking you too?

maxweisel•12/12/25, 1:43 PM

The best thing to do is to implement Oculus’s server to server entitlement API. Store your app keys on the backend and only send them to your app after they pass entitlement (which ensures it’s an unmodified build that has been installed via the store)

maxweisel•12/12/25, 1:43 PM

We also have a fingerprinting system. If you contact us, we can enable it, which will prevent your app key from being used anywhere else

maxweisel•12/12/25, 1:44 PM

coming in 2026, we’ll be launching our own server to server API that you can use to generate app keys on-demand so you can rotate them to prevent users from pulling them out of the build