It's not a good idea because of security issues my friend..! The application can be downloaded from users
I believe you are painting yourself into a corner.
You want to have external files - which would be downloaded to the users, right?
But for security you don't want the application to be downloaded? You DO realize that the ACCDE file isn't inherently encrypted, so if someone downloads the ACCDE they can get to the tables easily enough.
You want the file as an ACCDE so it can't be changed. But you want to have supplemental information including code modules in the addendum file - so as to change functionality.
These are self-contradictory goals. You need to come up to the surface and examine what you are really asking. This is a "forest vs. trees" situation.
I'm not trying to bust your chops here, so I'll go on to discuss my thoughts on how close you can come to what you describe.
The "list of extra data" such as URLs and IP addresses and other things could easily be done by having a secondary BE file of a predefined structure, for which the initial file has table definitions but the tables would be either be empty or would only contain whatever you want to use in the base version of your app. This app would ALWAYS have to look for the secondary BE file and map it. You would always have to include this file in the base release. Note that using a secondary BE file means that cross-file relational integrity will be impossible. RI cannot be enforced across files, only across tables in the same file.
At least in theory, as a mapped secondary BE file, it COULD contain code modules - but would ALWAYS have to have the same table names and call interfaces between the ACCDE's FE and this putative back end, no matter what else is in the file. In other words, because of the use of the ACCDE which is immutable, your interfaces would HAVE to be immutable, although what is "behind the scenes" of those interfaces could be anything. The interfaces would have to always be qualified by the name of the DB variable you used to open the secondary file.