In luna Mai 2017, 94,5% din cele 10 milioane de pagini web cele mai populare foloseau JavaScript. Cea mai obisnuita utilizare a JavaScript este sa-l adaugati la paginile HTML, cunoscute si sub numele de Dynamic HTML (DHTML).
Scripturile sunt incorporate sau incluse din paginile HTML si interactioneaza cu modelul de obiect document (DOM) al paginii. Cateva exemple simple de utilizare sunt:
- Incarcarea de continut de pagina noua sau trimiterea de date catre server prin Ajax fara a reincarca pagina (de exemplu, o retea sociala ar putea permite utilizatorului sa posteze actualizari de stare fara a parasi pagina).
- Animarea elementelor de pagina – le estompeaza in interior si in afara, le redimensioneaza, le muta etc.
- Continut interactiv, de exemplu jocuri si redare audio si video.
- Validarea valorilor de intrare ale unui formular Web pentru a va asigura ca sunt acceptate datele inainte de a fi trimise serverului.
- Transmiterea informatiilor despre obiceiurile de citire ale utilizatorului si activitatile de navigare pe diverse site-uri web. Paginile web fac acest lucru in mod frecvent pentru analize web, urmarire de publicitate, personalizare sau alte scopuri.
Codul JavaScript poate rula local in browserul unui utilizator (mai degraba decat pe un server de la distanta), crescand capacitatea de raspuns a aplicatiei la actiunile utilizatorului. Codul JavaScript poate detecta, de asemenea, actiuni ale utilizatorului pe care HTML singur nu le poate detecta, cum ar fi apasarile de taste individuale.
Aplicatii precum Gmail profita de aceasta: o mare parte din logica interfetei cu utilizatorul este scrisa in JavaScript, iar JavaScript transmite serverului cereri de informatii (cum ar fi continutul unui mesaj de e-mail). Tendinta mai larga a programarii Ajax exploateaza in mod similar aceasta putere.
Un motor JavaScript este un program de calculator care interpreteaza sau compileaza in timp real codul sursa JavaScript si executa scriptul in consecinta.
Primul motor JavaScript a fost creat de Brendan Eich la Netscape, pentru navigatorul Web Netscape Navigator. Motorul, numit cod SpiderMonkey, este implementat in C. De atunci a fost actualizat (in JavaScript 1.5) pentru a se conforma ECMAScript 3.
Motorul Rhino, creat in principal de Norris Boyd (anterior la Netscape, acum la Google) este un JavaScript cu implementare in Java. Acesta, la fel ca SpiderMonkey, este compatibil cu ECMAScript 3.
Un browser Web este cel mai comun mediu de gazda pentru JavaScript. Cu toate acestea, un browser Web nu trebuie sa execute cod JavaScript. (De exemplu, browserele bazate pe text nu au motoare JavaScript, iar utilizatorii altor browsere pot dezactiva scripturile printr-o preferinta sau o extensie.)
Un browser Web creeaza de obicei „obiecte gazda” pentru a reprezenta DOM in JavaScript. Serverul Web este un alt mediu de gazda comun. Un server Web JavaScript ar expune in mod obisnuit obiecte gazda reprezentand obiecte de solicitare si raspuns HTTP, pe care un program JavaScript le-ar putea interoga si manipula pentru a genera dinamic pagini Web.
JavaScript este singurul limbaj pentru care cele mai populare browsere impartasesc suport si a devenit din greseala un limbaj tinta pentru cadrele din alte limbi. Viteza crescanda a motoarelor JavaScript a facut ca limbajul sa devina o tinta de compilare fezabila, in ciuda limitelor de performanta inerente naturii sale dinamice.
Consideratii de compatibilitate
Deoarece JavaScript ruleaza in medii care variaza pe scara larga, o parte importanta a testarii si a depanarii este de a testa si verifica daca JavaScript functioneaza in mai multe browsere.
Interfetele DOM sunt definite oficial de W3C intr-un efort de standardizare separat de JavaScript. Implementarea acestor interfete DOM difera intre browserele web.
Autorii JavaScript pot face fata acestor diferente prin scrierea codului care respecta standardele, cod care poate fi executat corect de majoritatea browserelor. In caz contrar, ei pot scrie cod care se comporta diferit in absenta anumitor functii ale browserului.
Autorii pot considera, de asemenea ca fiind practic sa detecteze ce browser ruleaza, deoarece doua browsere pot implementa aceeasi caracteristica cu un comportament diferit. Bibliotecile si seturile de instrumente care iau in considerare diferentele de browser sunt, de asemenea, utile programatorilor.
Mai mult, este posibil ca scripturile sa nu functioneze pentru unii utilizatori. De exemplu, un utilizator poate:
- utiliza un browser vechi sau rar, cu suport DOM incomplet sau neobisnuit;
- utiliza un browser PDA sau telefon mobil care nu poate executa JavaScript;
- a dezactivat JavaScript ca masura de securitate;
- utilizeaza un browser cu voice/speak recognition (recunoasterea vorbirii) din cauza, de exemplu, unei dizabilitati vizuale.
Pentru a sprijini acesti utilizatori, autorii web pot incerca sa creeze pagini care se axeaza pe nevoile utilizatorului. In special, pagina ar trebui sa ramana utilizabila, desi fara functiile suplimentare pe care le-ar fi adaugat JavaScript.
Unele site-uri folosesc eticheta HTML <noscript>, care contine alt continut daca JS este dezactivat. O abordare alternativa pe care multi o considera preferabila este sa introduca mai intai continut de autor folosind tehnologii de baza care functioneaza in toate browserele, apoi sa imbunatateasca continutul pentru utilizatorii care au JavaScript activat. Aceasta practica mai este cunoscuta ca “imbunatatire progresiva”.
Vulnerabilitati cross-site
O problema comuna de securitate legata de JavaScript este scriptul cross-site (XSS), o incalcare a politicii cu aceeasi origine. Vulnerabilitatile XSS apar atunci cand un atacator este capabil sa provoace un site Web tinta, cum ar fi un site web bancar online, sa includa un script rau intentionat in pagina web prezentata unei victime.
Scriptul din acest exemplu poate accesa apoi aplicatia bancara folosind privilegiile victimei, dezvaluind potential informatii secrete sau transferand bani fara autorizatia victimei. O solutie la vulnerabilitatile XSS este de a utiliza HTML ori de cate ori se afiseaza date de incredere.
Unele browsere includ o protectie partiala impotriva atacurilor XSS reflectate, in care atacatorul furnizeaza o adresa URL, inclusiv scripturi daunatoare.
Cu toate acestea, chiar si utilizatorii acestor browsere sunt vulnerabili la alte atacuri XSS, cum ar fi cele in care codul rau intentionat este stocat intr-o baza de date. Doar proiectarea corecta a aplicatiilor Web din partea serverului poate preveni complet XSS.
Vulnerabilitatile XSS pot aparea si din cauza greselilor de implementare ale autorilor browserului.
O alta vulnerabilitate a mai multor site-uri este falsificarea cererilor de site-uri (CSRF). In CSRF, codul de pe site-ul unui atacator pacaleste browserul victimei sa intreprinda actiuni pe care utilizatorul nu a intentionat sa le produca, pe un site tinta (cum ar fi transferul de bani la o banca).
Atunci cand site-urile tinta se bazeaza exclusiv pe cookie-uri pentru autentificarea solicitarilor, solicitarile provenite din cod pe site-ul atacatorului pot purta aceleasi certificate de autentificare valabile ale utilizatorului initiator.
In general, solutia CSRF este de a cere o valoare de autentificare intr-un camp de forma ascunsa, si nu numai in cookie-uri, pentru a autentifica orice solicitare care ar putea avea efecte de durata. Verificarea antetului HTTP Referrer va poate ajuta in acest sens.
„Deturnarea JavaScript” este un tip de atac CSRF in care o eticheta <script> de pe site-ul unui atacator exploateaza o pagina de pe site-ul victimei care returneaza informatii private, cum ar fi JSON sau JavaScript.
