You may adopt different strategies to do that, not necessarily using TEAL.
Since, as you said, anyone would be able in principle to create any ASA they like, one think you may want to ensure is that “legit ASAs”, for the purposes of your application, are just those one either:
-
Created by a [2/2] MultiSignature account, composed by the Issuer to be paid once for the ASA issuance and the account of the User that requires those ASA. This approach let you collect the one time fee and scale up against the 1000 ASA per account limit.
-
Created through an Atomic Transfer that include the ASA create transaction, signed by the Issuer, and the payment from the User to the Issuer.
Both those approaches require that your application knows how to differentiate between “legit ASAs” and “fake ASAs” based on client-side checks.
A more decentralised approach would involve TEAL as a mean of ASA create approval on chain, to enforce directly process on ASA creation. You can find one example of this approach here.