Dictionary path construction improvement

[monolithed]

Hi,

I noticed that the dictionary path is built using the key name. I think this could be insecure, because the key might contain a slash (/), which could potentially be used to access the file system and execute arbitrary code. I'm pretty sure there's a potential attack vector there.

CWE-73, CWE-22

Also, this would allow human-readable keys like namespace/my-key, right now, the / breaks dictionary access.

[aymericzip]

Good catch, again @monolithed

Fixed in f085d9d

Will be merge in 8.9.8
Closing it

[aymericzip]

40f121e

Updated to block nullbit injection, and multiple separators like my._-key

[monolithed]

@aymericzip

I think we need to decouple translation keys from filesystem structure. Banning characters is just a delayed solution
The current approach couples keys to file paths, makes the system fragile and introduces implicit constraints:

• key depends on file structure
• any file move breaks keys
• filesystem becomes part of the public contract
• potential issues with Unicode normalization and OS path semantics
• not obvious for users, they don't realize there are restrictions on what characters can be used in keys

Instead, we should introduce a build-time manifest, where keys are fully independent identifiers.

Current behavior

key → derived filesystem path → runtime lookup

Proposed behavior

key → manifest → path/module

{
  "/$%^&*IOK/BVBNKL": "./contact-form/subject/index.content.ts"
}

I might not see the whole picture yet, but in i18next any keys are allowed. So why can't we just do the same?

[aymericzip]

Hi @monolithed

Yeah I see your point, and you're 100% right. I'm also thinking about improvements regarding that flow.

I also do not like rebuilding of json needed to after each .content update, it adds a lot of extra logic.

I'm listing two constraints right now:

• build optimization.
  At build time, intlayer replace the centralize entry point like useIntlayer('my-key') into useDictionaryDynamic({ en : import('../../../.intlayer/dynamic-dictionaries/my-key.json').them(m => m.json())}) , and other equivalent for getIntlayer, and static loading mode. That's says, a prepared version on that json at build time should be present.

• CMS content & key content merging:
  Intlayer merge local .content content and CMS content based on that key, and priority set up. We have to ensure this merging logic is not impacting.

So I will keep the key restriction in a first time, but I'm definitely open to improvement suggestions