Despite my profession, I've never attested to know much about computers, a fact I'll now undoubtedly prove.  I'm wondering if because of the apparently inherent nature of Ajax programming to be a performance concern in executing remote server-side scripts on an per-client-side event basis, potentially firing in rapid succession (which in cases of data access wired up to keypress events can reasonably be a fairly large concern), does this open a dangerous window in the case of form-based data input to injection attacks?

If people can immediately see or easily extract your client-side code (either through embedded code or through <script> tags), they figure out what remote script you're calling through XMLHTTP, and write a malicious program to repeatedly fill out this form with harmful data, right?  Or just hammer the server until it's overloaded with request traffic, to the point when its shuts down, unable to take the weight?  Could this be a potentially catastrophic danger to web apps, a hybrid of a SQL injection attack, malicious cross-site scripting and blog spamming? 

After discussing the above argument offline with some friends pretty into Ajax at the moment - Wally, Michael, Craig and Glav - the general consensus appeared to be that the de facto Ajax programming model is naturally flawed at the current time, and that HTTP can still be threatened by way of a denial of service attack at any time, Ajax or not.  The solution would be proper implementation of best practices development, considering service-oriented architecture to ensure optimal security and proper performance.

Wally says - "It is highly likely that if you go back to the server too much, even a relatively small application will overload its server.  IIS and ASP.NET keeps a threadpool of 25 threads per cpu available on the server to process.  This value is modifiable.  I've run with a threadpool of 50 and 75 threads per cpu and it greatly improved the performance of a server farm running a single application where the application made a number of small/highly optimized operations."

Michael says - 'Malicious/selfish users might tweak the client-side a bit to gain an advantage. For example, you could easily drop the period between refreshes. I wrote about this risk at http://ajaxpatterns.org/Submission_Throttling under 'How to protect against "impatient" clients?'"

Craig says - "All the old rules of best practices and good application architecture will apply to AJAX. Validate your input and put safeguards on your services. AJAX is still a HTTP request so you have context information at your disposal. You could look at IP addresses and other such information to safeguard against denial of service attacks, you could create a unique session ID or ticket that would only come from a trusted source and evaluate this value BEFORE any processing."

Glav says - "I think more abuse will come from overuse or bad practices when using Ajax.  Because of the 'invisible' nature of the postback, the effects of excessive and/or long running postbacks are less evident.  I think it can be open to malicious attack too, but only in the same way that standard web apps are today. If its critical stuff, the standard defensive measures should apply, much like you would design into your services in an SOA application."

I guess the larger concern would be that for the moment, developers code Ajax-based applications *very* defensively.  I'm finding that the more I learn about Ajax in its current state, the more I worry.