The Office Dev Patterns and Practices repo on GitHub has a great sample for provisioning custom web parts on the host web from inside of an app which should be a viable option for your situation. You could use this pattern to allow users to retrieve a custom configured web part and have it inserted into their host web allowing them to insert it at will (you could also programatically insert it on specific pages and that is demonstrated in one of the sample projects). To create the custom web part you can export a pre-configured webpart as a .webpart
file from within the UI (or using various other techniques) in order to avoid needing a sandbox or farm solution.
The "AppScriptPart" sample (the name they're calling it) can be found here: https://github.com/OfficeDev/PnP/tree/master/Samples/Core.AppScriptPart
Steve Walker from the Office 365 team also does a nice demo of the technique involved here as part of a course offered as the Microsoft Virtual Academy. You'll be interested in the course called "Transform SharePoint Customizations to SharePoint App Model" -- Module 4, starting at 17:29 (pick "UX Customizations with app model" from the right hand menu) should provide you with a much better overview of the process than I can explain here.
The sample and video demonstrate a provider hosted app, but I have re-built most of the sample using the JavaScript Object Model as well, so you could use a SharePoint hosted app for this purpose as well. The major difference there (other than hosting requirements) is that in a provider hosted app it's possible for the app to perform operations that a user may not have permissions for (such as adding the webpart to the webpart library or inserting it on a page), while on a SharePoint hosted app, the user accessing the app (and the app itself, just like with provider hosted) would need to have the right permissions to perform the action.
When a webpart is used like this, there are no cross domain issues to overcome, because the webpart is loaded directly on the host web page (not in an IFrame) and runs completely within the context of the hosting page.
Update: I'm sharing a working version of a SharePoint hosted app in Napa that will install a webpart into your webpart gallery that reads the querystring and modifies a DOM element on your page (just as your question proposed). You can install it directly to your (or your development) O365 environment if you have installed Napa -- which is free when using O365/SPO. Note this is not production level code: it will break MDS, the webpart installs under the miscellaneous group because I don't bother to change it, the webpart will not work if the app is uninstalled (since the app web location hosting the script will change) and I'm certain there are many improvements that you could make. My intent is just to demonstrate the possibilities.
The app will install a web part into your webpart gallery that you can insert on a page; the webpart will then display information from the querystring and modify a DOM element on the current page.
After you run the scenario in the full screen app page, the webpart will be inside of your webpart gallery. You install the webpart as a normal webpart (not an app part): edit the page, from the ribbon to go Insert => WebPart => Miscellaneous => QueryString Display => Add
If the QueryStringDisplay webpart doesn't show you any values after Your QueryString is:
manually add a querystring value with something like ...aspx?something=1
You could modify the app so that it provisions the web part into the galleries of a number of different site collections (provided the person running the app had permissions to all of those site collections).
You'll have to trust it with full control on the host web (since that is the permission needed to upload webparts into the webpart gallery) but you should easily be able to review the code and see precisely what it does (and that it is safe to run). All of the logic is contained in App.js
and webPartScript.js
Here is the link: http://aka.ms/J08vgz