Voor de optimale veiligheid moet je alle script-vormen die terug kunnen communiceren verbieden.
Het zijn (vaak) onnodige en achterhaalde dingen,met maar een paar (mogelijke) uitzonderingen.
Noscript is dan ook één van de oplossingen.

Noscript voor IE? Noscript is er alleen voor mozilla based browsers.

Hier zie je weer de omgekeerde wereld van Mico$oft. Als je het goed wilt doen, dan zet je VBScript per definitie uit, en moet je als gebruiker deze zelf actief aanzetten. Dat is vele malen beter en veiliger. Gok dat er nog maar weinig sites zijn met VBScript. Dus niemand zal het dan doen.

Maar het zelf uitzetten van iets wat je niet gebruikt, dat doet niemand, want men weet niet dat het aan staat. Want ze gebruiken het niet. Of te wel, dit gaat niets oplossen qua virussen en veiligheid.

Maar ja, wie wil er dan nog uberhaupt IE gebruiken....

TheYOSH

Script oplossingen i.c.m. Ajax in de browser achterhaald?

http://swerl.tudelft.nl/twiki/pub/Main/SpciProject/mesbah-informatie06.pdf

Half internet draait daar ondertussen op en dat gaat alleen maar meer worden.

wow... en dat na pas 20 jaar ellende... dat is vlug.

Dat is met meer (achterhaalde) standaarden het geval.
Met HTML5 zijn (de meeste/veel) dingen, die vroeger alleen met een script mogelijk waren, verleden tijd geworden.

Kijk b.v. naar responsive websites, het probleem is verplaatst naar de cliënt, dus terug-communicatie is niet nodig.
Een ander achterhaalt ding is flash, en over Silverlight wil ik het helemaal niet meer hebben, maar dat zijn geen scripts.

Noscript is er voor vele browsers, bij een aantal is het zelfs standaard ingebouwd (o.a. Opera en Midori).

Voor de veiligheid is iedere vorm van een script, dat op de cliënt wordt uitgevoerd en dat terug communiceert naar de server een mogelijk probleem..........

Nog nooit van gehoord. Even snel je link bekeken....

IE11 ondersteund het al niet. Dan is het eigenlijk al geen standaard... .Dit is gewoon een veel gebruikte browser in bedrijven en zonder ondersteuning daarvan,
FF ESR ondersteund het niet helemaal.
Android 5.x ondersteund het nog niet goed, wat toch ook echt nog veel gebruikt wordt.

Dus standaard is nog erg "grof" qua bewoording.

Als iedereen het dus zou gebruiken, dan kunnen een hoop gebruikers in eens niet meer op het Internet surfen...... Niet echt praktisch voor een standaard.

Je beeld klopt niet erg: ca. 95% v.d. websites gebruikt JavaScript en Single Page Apps zijn in opkomst. Responsive design is maar een klein deel van wat moderne websites met JavaScript doen. HTML5 staat hier los van.

https://w3techs.com/technologies/details/cp-javascript/all/all

Ik snap dat je on redenen van veiligheid eigenlijk alleen statische pagina's zou willen. Dat gaat echter niet gebeuren want mensen willen meer van moderne sites dan daarmee geboden kan worden. Dat je met noscript en dergelijke meer controle wilt krijgen over wat er al dan niet wordt uitgevoerd, alla.

Bovendien is JavaScript qua veiligheidsimpact niet vergelijkbaar Flash of een andere browserplug-in. Het kan bv. niet bij het bestandssysteem, of slechts beperkt, via de HTLM5 FileSystem API (sandboxed bestandssysteem).

Als je het echt bekeken had had je moeten opvallen dat de gangbare aanduiding java script is. Dat is de naam die een webaap hanteert. Wordt ondersteund in alle browsers met Ajax het interactieve element.

"Even snel" betekent bij jou kennelijk dat je de tweede zin van het gelinkte Wikipedia-artikel al niet meer gelezen hebt, die begint met: "It was created to standardize JavaScript".

Dat het nog bestaat verbaast me niet, dat het vandaag de dag nog zonder het expliciet aan te moeten zetten in een browser wordt ondersteund is inderdaad bizar. IE3 ondersteunde al JScript, Microsoft's JavaScript-implementatie. De tijd dat IE4.x Netscape 4.x over elkaar heen duikelden qua nieuwe mogelijkheden (ook in JavaScript) was ook de tijd dat bedrijven het web begonnen te omarmen als vervanging voor native applicaties bij klanten. De belofte van het web was toen dat de eindeloze compatibiliteitsproblemen die ze bij het installeren van applicaties bij klanten tegenkwamen met een webinterface tot het verleden zouden gaan horen. Dat viel tegen natuurlijk, als je het onderste uit de kan wilde halen qua geliktheid was je in die tijd aangewezen op features die niet zo compatibel of stabiel waren, maar voor een webontwikkelaar die in die tijd een beetje verder keek dan zijn neus lang was was het evident dat VBScript in de browser geen optie was om je compatibele applicaties op te baseren omdat er simpelweg maar één browser was die het ondersteunde. De subset van mogelijkheden binnen JavaScript die stabiel was was een veel betere basis, en het was duidelijk dat die stabiele basis alleen maar zou groeien.

En toch liepen er hordes mensen rond die uit die combinatie van omstandigheden niet concludeerden dat je beter JavaScript dan VBscript als uitgangspunt kon nemen. Commerciële types kijken naar marktaandeel. Die zagen dat IE de grootste is en vonden dat we ons dus op IE moesten richten. Open deur, in hun ogen. Dat de door alle mainstream browsers gedeelde subset van standaards een basis opleverde die nagenoeg 100% marktaandeel vertegenwoordigde en ook nog bestand was tegen verschuivingen in dat aandeel bleek erg moeilijk uit te leggen te zijn aan deze groep mensen. Dat we klanten in het midden-oosten hadden waar dankzij de eerste golfoorlog bedrijven waren met personeel dat het verdomde met Amerikaanse software te werken deed het muntje een beetje vallen. Dat in Duitsland Firefox de 30% gebruiksaandeel al passeerde terwijl in Nederland IE nog ver boven de 90% zat deed ook wat lampjes branden. Maar het was moeizaam en moest keer op keer herhaald worden, het idee dat het maximale marktaandeel niet bij een produkt maar bij gedeelde eigenschappen van soortgelijke produkten ligt is kennelijk erg moeilijk, zelfs terwijl dat precies de reden was geweest om het web als applicatieplatform te omarmen. Dat je het voordeel van zo'n benadering meemaakt elke keer dat je een stekker in een stopcontact steekt (het werkt gewoon, de fabrikant doet er niet toe) is een beeld dat kennelijk moeilijk naar webstandaards te vertalen is.

Ik kwam later groepjes ontwikkelaars tegen die enthousiast losgingen op het maximaal uitmelken van de mogelijkheden van een specifieke browser, IE6. En dat ging het best met VBscript, want dat gaf via ActiveX toegang tot heel veel buiten de browser geïmplementeerde mogelijkheden van de client-machines (mogelijkheden die natuurlijk ook beveiligingsrisico's waren). Het resultaat was oogstrelend, maar ik was zo'n lastige beoordelaar die vroeg hoe het eruit zag in Firefox of Opera. Ik heb meegemaakt dat mensen die al uitgebreid complexe webapplicaties hadden gebouwd verbluft waren om te zien dat het niet gewoon werkte maar compleet instortte, om vervolgens het platform waarin ze zoveel inspanning geïnvesteerd hadden maar te gaan pushen als norm omdat het te pijnlijk was om al hun inspanningen te devalueren. Alleen was ook daar onafhankelijkheid van wat op klantmachines mogelijk was nog steeds de reden geweest om het web als platform te gaan gebruiken. Ze hadden in hun enthousiasme het centrale uitgangspunt van die hele excercitie genegeerd.

Ik neem aan dat dit soort dingen de redenen zijn geweest voor Microsoft om de VBScript-ondersteuning zo lang te handhaven. Nadat ze het zelf ooit actief in de hand hebben gewerkt, overigens, toen ze vrijwel monopolist waren vonden ze non-standaard webapplicaties helemaal niet erg, dat bond mensen aan hun platform. Wat ik bizar vind is dat het overstappen van VBscript default aan naar default uit nu pas plaatsvindt. Een publiek toegankelijke website die VBScript gebruikt was voor zover ik me herinner vijftien jaar geleden al een zeldzaamheid. Bedrijven kunnen voor hun interne applicaties centraal de ondersteuning aanzetten, als Microsoft zo'n instelling ondersteunt, en instellingen die het mogelijk maken om VBScript alleen op specifieke websites toe te staan overstijgen het intellectuele vermogen van een grote softwarefabrikant echt niet. Dit had dus veel eerder al op een degelijke manier geregeld kunnen zijn.

95% van de websites voldoet ook niet aan de W3C standaard, deze zijn dan ook meestal gemaakt door mensen die geen kennis hebben van HTML.
Voor een responsive website heb je geen JavaScript nodig, met CSS is het zelfs simpeler, sneller en beter ondersteund.

Mogelijk ben ik te oud, maar ........
Een website is primair bedoeld, om informatie over te brengen, liefst op een goed leesbare en aantrekkelijke manier.
Dit lukt mij prima zonder JavaScript.
Nu heb ik niets tegen een cliënt site scripting, maar wel wanneer deze terug communiceert naar de server.
Voor mij is dat nog redelijk simpel te controleren, maar voor buitenstaanders kan dit vele gevaren opleveren, je hebt (bij een standaard installatie) geen controle over wat er terug wordt verzonden.
Voor mij is dit ook de reden geweest, om meerdere browsers te gebruiken, waarvan de configuraties verschillen.

Gegevens terugsturen naar de server, zonder tussenkomst van de "bedienaar".
Dit kan een onschuldig iets zijn, zoals de grootte van het venster (Wat viewport heet in CSS), maar het kunnen ook andere gegevens zijn, die op je hardeschijf staan en toegankelijk zijn voor het script, onder het gebruikers account.
Er zijn b.v. scripts in omloop, die de registry scannen op bepaalde trefwoorden, dit kan erg gevaarlijk zijn, maar ook de privacy schenden.

Edit: zie ook http://www.nporadio1.nl/wetenschap-techniek/3841-wachtwoorden-mobiel-perfect-te-hacken-via-je-touchscreen