In the CONNECTION, never in a mapping, a lookup or a JavaScript library. What is encrypted, what is exportable, and the export that carried a secret to a laptop.
The connection is the only place OIC treats a value as a secret. It is stored encrypted, it is not displayed back after saving, and the platform knows it must be handled differently from configuration.
THE THREE WRONG PLACES ARE ALL REACHABLE AND ALL LOOK LIKE THEY WORK. A token hard-coded in a mapping is visible to anybody who opens the mapper. A password in a lookup sits in a table Module 11 established has no version history and a wider edit permission than the integration itself. A key in a JavaScript library is worst: it is in code nobody reads and nothing in the console suggests it is there.
AND THE EXPORT IS THE FAILURE THIS LESSON EXISTS FOR. Exporting an integration is routine — it is the promotion mechanism, and it is how somebody takes a copy to look at. The export carries whatever is IN the integration, so a secret hard-coded in a mapping or a library travels with it: into a file, onto a laptop, into an email, into a ticket attachment, possibly into a source repository.
The connection's credential does NOT travel that way, which is precisely the property that makes the connection the right place — and it is why the promotion process in Module 16 has a separate step for supplying credentials in the target environment.
SO THE CHECK BEFORE ANY EXPORT LEAVES THE PLATFORM IS: what secret is inside this file? Open it and look, once, until you trust the estate. A hard-coded secret that has been exported is not fixed by editing the integration — it is fixed by rotating the credential, which is Lesson 6 and considerably more work.