Idag utförs arbete ofta på resande fot och då används smarta telefoner och surfplat- tor istället för datorer. Dessa skärmar är oftast mindre än vad en datorskärm är. Där- för efterfrågas en mer dynamisk design av webbsidor som anpassar sig till storleken på skärmen. Webbsidans statiska design var 1000 pixlar bred och innehöll många tabeller vilket skulle få plats i den dynamiska designen med en minsta bredd på 320 pixlar. En del viktig information behövde även lyftas fram och göras tydligare. Det implementerades en ny CSS-mall samt flera nya JavaScript. En del HTML justerades för att passa den nya CSS-mallen. Eftersom en del viktig information behövdes pre- senteras tydligare skapades en helt ny flik. Innehållet blev driftinformation relaterat till den inloggade kunden. Efter simuleringarna i Chrome verifierades responsivite- ten av sidorna på alla skärmstorlekar. Implementeringen av AJAX gjorde att de lång- samma sidorna svarade direkt, men förbättrade inte den totala laddtiden. För att förbättra den skulle en back-end optimering behöva utföras. Projektets webbsida fu- gerade enligt önskemål. / In today ́s society people are working more and more while travelling, which makes them use smartphones and tablets instead of laptops. These screens are usually smaller than a laptop screen. That is why a more dynamic web design has been re- quested in order to fit the screen on the device being used. The static webpage’s width was 1000 pixels and the goal was to fit all the tables and information in the respon- sive version with a width of 320 pixels. Important information also had to be moved to a different page in order to make it more visible. A new CSS-template was imple- mented and several new Java Scripts followed by finer adjustments to the HTML code. Since some information had to be more visible to the user, a new tab was cre- ated in order to fulfill this demand. The new tab contained information about “Net- work Status” only related to the signed in user. After simulating the webpage in Chrome the responsiveness of the page was confirmed on all screen sizes. Sending the webpage asynchronously made the slow pages respond instantly but the total loading time was still slow. To fix this, back-end programming would have been re- quired. The project’s webpage fulfilled all the requirements.

Syftet med denna studie har varit att undersöka ifall det är möjligt att utveckla ett användargränssnitt i form av ett webbläsartillägg för Ladok som är ett resultatsystem för universitet och högskolor i Sverige. En del av studien har också varit att kunna utvärdera minst ett sätt att skapa webbläsartillägg. Enkätundersökningar samt intervjuer gjordes för att kunna förstå vilka typer av funktioner som skulle kunna vara till nytta för studenter samt lärare i ett sådant användargränssnitt. Det gjordes även GUI prototyper i designverktyget Figma som det gjordes användartester på. Den största utmaningen under arbetet har varit att kunna dra en slutsats om det är möjligt att kunna få tillgång till data från Ladok med hjälp av webbskrapning och API-förfrågningar. Datat på Ladok är sekretessbelagt eftersom Ladok innehåller konfidentiell information. Det har därför varit svårt att få tillgång till data under projektets gång. Olika typer av metoder testades under projektets gång för att se om det skulle kunna gå att få tillgång till data för att kunna utveckla ett användargränssnitt för Ladok. Slutsatsen som kan dras för detta projekt är det krävs mer forskning och tid samt att det inte finns någon lösning på detta än. Framtida arbete som är värt att nämna är kunna implementera användarskript som endast körs när studenter är inloggade på Ladok. Ett exempel på ett verktyg som kan användas för detta ändamål är TamperMonkey som är kompatibelt med Google Chrome. GreaseMonkey är motsvarar TamperMonkey, men är kompatibelt med Mozilla Firefox. / The objective of this study has been to examine if it is possible to develop a user interface as a browser extension for Ladok which is a result system that is used by higher education institutions such as colleges and universities in Sweden. A part of the study has also been to be able to evaluate at least one method of developing browser extensions. Interviews and surveys were conducted in order to understand what types of functions that would be beneficial for both students and teachers in such a user interface. GUI mockups were created in the design tool Figma and were later measured through usability tests. The main challenge during the study has been to be able to determine if it is possible to access data from Ladok through web scraping and API requests. As Ladok consists of confidential information about students, the data is private. Due to this it has been very difficult to be able to gather data. Different types of methods and approaches were used in order to determine if it would be possible to develop a user interface for Ladok. The conclusion that can be drawn is that more research and time are needed and that there is no clear solution for this yet. Future work could be to develop user scripts that would only run when Ladok would be used. An example of a tool for user scripts is TamperMonkey, which is compatible with Google Chrome. GreaseMonkey is equivalent to TamperMonkey, but is compatible with Mozilla Firefox.

There has recently been an emergence of new devices in which users can access the web. These devices have significantly smaller screen sizes than the more common desktop. This results in that the approach to designing web content has to be changed. The approach to design web content that adapts its visual layout to different screen sizes, is referred to as Responsive Web Design. Ida Infront is a company that develops systems and solutions for informationintensive businesses. They are currently examining how to design a layout editor that can be used to define responsive design for web-forms. The purpose of this project is to design and implement a prototype of such a layout editor, which will then be evaluated by Ida Infront. The project is divided into two phases, starting out with the research process, followed by the prototype design process. In the research process, the following is examined: structure of the XML file describing web-forms, Responsive Web Design techniques and technologies appropriate for the layout editor. In the prototype design process, a layout editor prototype allowing responsive design for web-form components, is designed and implemented. The responsive design configuration is added to the web-form XML file. We found that Bootstrap is a suitable technology to define responsive design of web-forms, since placement of web-form components can be translated into a Bootstrap grid system. The resulting layout editor prototype allows responsive configuration in Bootstrap. This is done by utilising the grid system as the underlying structure for placement of web-form components. The prototype also allows configuration for each of the four Bootstrap device classifications, named xs, sm, md and lg. Position and size of webform components are stored for each Bootstrap device classification. The resulting responsive configuration is added into the existing XML file for the web-form. / Den senaste tiden så har det uppkommit nya enheter som man kan komma åt webben med. Dessa enheter har betydligt mindre skärmar än de mer vanliga stationära enheterna. Det har resulterat i att sättet man designar webbinnehåll måste ändras. Metoden att designa webbinnehåll så det anpassar sin grafiska utformning efter olika skärmstorlekar kallas för responsiv webb design. Ida Infront är ett företag som utvecklar system och lösningar för informationsintensiva verksamheter. De undersöker just nu hur man designar en layout editor som kan användas för att definiera responsiv design för webb-formulär. Syftet med detta projekt är att designa och implementera en prototyp av en sådan layout editor, som sedan kommer utvärderas av Ida Infront. Examensarbetet är uppdelat i två faser, det inleds med forskningsfasen och efterföljs av prototypfasen. I forskningsfasen undersöks följande: strukturen i XML filen som beskriver webb-formulär, olika tekniker för responsiv webb design och lämpliga teknologier att använda i en layout editor. I prototypfasen, designas och implementeras en prototyp som gör det möjligt att definera responsiv konfiguration för webb-formulär. Konfiguration för responsiv design läggs till i den befintliga XML filen. Vi kom fram till att Bootstrap är en lämplig teknologi för att definera responsiv design för webb-formulär. Eftersom placeringen av komponenter i webb-formulär kan översättas till Bootstraps rutnät. Den resulterande layout editorn gör det möjligt att definera responsiv design i Bootstrap. Detta genom att använda Bootstraps rutnät som underliggande struktur för placering av webb-formulärets komponenter. Prototypen gör det också möjligt att konfiguera för var och en av de fyra Bootstrap enhets klasserna, namngivna som xs, sm, md och lg. Position och storlek för webb-formulärets komponenter lagras för varje Bootstrap enhets klass. Den resulterande responsiva konfigurationen läggs till i den befintliga XML filen för webb-formuläret.

It has become an important part of business development to collect statistical data from online sources. Information about users and how they interact with an online source can help improving the user experience and increasing sales of products. Collecting data about users has many benefits for the business owner, but it also raises privacy issues since more and more information about users are spread over the internet. Tools that collect statistical data from online sources exists, but using such tools gives away the control over the data collected. If a business implements its own analytics system, it is easier to make it more privacy centric and the control over the data collected is kept.  This thesis examines what techniques that are most suitable for a system whose purpose is to collect, store, process, and present large-scale privacy centric data. Research about what technique to use for collecting data and how to keep track of unique users in a privacy centric way has been made as well as research about what database to use that can handle many write requests and store large scale data. A prototype was implemented based on the research, where JavaScript tagging is used to collect data from several online sources and cookies is used to keep track of unique users. Cassandra was chosen as database for the prototype because of its high scalability and speed at write requests. Two versions of the processing of raw data into statistical reports was implemented to be able to evaluate if the data should be preprocessed or if the reports could be created when the user asks for it.   To evaluate the techniques used in the prototype, load tests of the prototype was made where the results showed that a bottleneck was reached after 45 seconds on a workload of 600 write requests per second. The tests also showed that the prototype managed to keep its performance at a workload of 500 write requests per second for one hour, where it completed 1 799 953 requests. Latency tests when processing raw data into statistical reports was also made to evaluate if the data should be preprocessed or processed when the user asks for the report. The result showed that it took around 30 seconds to process 1 200 000 rows of data from the database which is too long for a user to wait for the report. When investigating what part of the processing that increased the latency the most it showed that it was the retrieval of data from the database that increased the latency. It took around 25 seconds to retrieve the data and only around 5 seconds to process it into statistical reports. The tests showed that Cassandra is slow when retrieving many rows of data, but fast when writing data which is more important in this prototype. / Det har blivit en viktig del av affärsutvecklingen hos företag att samla in statistiska data från deras online-källor. Information om användare och hur de interagerar med en online-källa kan hjälpa till att förbättra användarupplevelsen och öka försäljningen av produkter. Att samla in data om användare har många fördelar för företagsägaren, men det väcker också integritetsfrågor eftersom mer och mer information om användare sprids över internet. Det finns redan verktyg som kan samla in statistiska data från online-källor, men när sådana verktyg används förloras kontrollen över den insamlade informationen. Om ett företag implementerar sitt eget analyssystem är det lättare att göra det mer integritetscentrerat och kontrollen över den insamlade informationen behålls. Detta arbete undersöker vilka tekniker som är mest lämpliga för ett system vars syfte är att samla in, lagra, bearbeta och presentera storskalig integritetscentrerad information. Teorier har undersökts om vilken teknik som ska användas för att samla in data och hur man kan hålla koll på unika användare på ett integritetscentrerat sätt, samt om vilken databas som ska användas som kan hantera många skrivförfrågningar och lagra storskaligdata. En prototyp implementerades baserat på teorierna, där JavaScript-taggning används som metod för att samla in data från flera online källor och cookies används för att hålla reda på unika användare. Cassandra valdes som databas för prototypen på grund av dess höga skalbarhet och snabbhet vid skrivförfrågningar. Två versioner av bearbetning av rådata till statistiska rapporter implementerades för att kunna utvärdera om data skulle bearbetas i förhand eller om rapporterna kunde skapas när användaren ber om den. För att utvärdera teknikerna som användes i prototypen gjordes belastningstester av prototypen där resultaten visade att en flaskhals nåddes efter 45 sekunder på en arbetsbelastning på 600 skrivförfrågningar per sekund. Testerna visade också att prototypen lyckades hålla prestandan med en arbetsbelastning på 500 skrivförfrågningar per sekund i en timme, där den slutförde 1 799 953 förfrågningar. Latenstest vid bearbetning av rådata till statistiska rapporter gjordes också för att utvärdera om data ska förbehandlas eller bearbetas när användaren ber om rapporten. Resultatet visade att det tog cirka 30 sekunder att bearbeta 1 200 000 rader med data från databasen vilket är för lång tid för en användare att vänta på rapporten. Vid undersökningar om vilken del av bearbetningen som ökade latensen mest visade det att det var hämtningen av data från databasen som ökade latensen. Det tog cirka 25 sekunder att hämta data och endast cirka 5 sekunder att bearbeta dem till statistiska rapporter. Testerna visade att Cassandra är långsam när man hämtar ut många rader med data, men är snabb på att skriva data vilket är viktigare i denna prototyp.

Det finns många ramverk för att optimera utveckling av en webbapplikation. Angular, React och Vue är tre av de största JavaScript baserade front-end ramverken för utveckling av webbapplikationer. Eftersom de är bland de populäraste JavaScript ramverken vill den här studien bidrar den här studien att utvidga kunskapen om JavaScript ramverk. Detta för att göra det lättare att välja ett Java-Script ramverk som passar för utvecklarens behov. Syftet med denna studie är att med hjälp av tre olika webbapplikationer skapade i Vue, Angular och React, gjordes en jämförelse för att mäta prestandan av bilder och video. Med denna jämförelse går det att se vilket ramverk som presterar bäst och underlättar valet av ramverk.En litteraturstudie gjordes för att införskaffa kunskap om hur de olika ramverken implementeras och hur tidigare studier inom detta område gått tillväga. Tre webbapplikationer skapades i Vue, React och Angular. Dessa applikationer hölls så lika som möjligt för att minimera faktorer. De testades sedan genom att göra tre separata test med verktyget Lighthouse där 20, 40, 100 och 200 bilder och videos testades i dessa mängder. Resultatet ställdes upp i tabeller och analyserades mellan de olika ramverken. Resultatet var att Angular fick sammanfattad poäng på 737, Vue hade 745 och React hade 747. Slutsatsen visar att React prestera bäst på rendering av videos. Vue presterade bäst på bilder. Angular var det sämst presterande ramverket på majoriteten av kriterierna. React presterade bäst om alla resultat läggs ihop. Vid webbapplikationer som hanterar bilder rekommenderas Vue att användas i övriga fall rekommen-deras React. / There are many ramverk for optimizing the development of a web application. Angular, React and Vue are three of the largest JavaS-cript based front-end ramverk for webpage development. As these are among the most popular JavaScript ramverk, this study wants to help expand your knowledge of JavaScript ramverk. This is to make it easier to choose a JavaScript framework that suits the devel-oper's needs. The purpose of this study is to use three different web applications created in Vue, Angular and React. A comparison was made to measure the performance of images and video. With this comparison, it is possible to see which framework performs best and facilitates the choice of framework.A literature study was conducted to acquire knowledge of how the various ramverk are implemented and how previous studies in this area have proceeded. Three web applications were created in Vue, React and Angular. These applications were kept as equal as possible to minimize factors. They were then tested by doing three separate tests with the tool Lighthouse where 20, 40, 100 and 200 images and videos were tested in these quantities. The results were presented in tables and analysed between the different ramverk. The result was that Angular got a total score of 737, Vue had 745 and React had 747. The conclusion is that React performs best in rendering videos. Vue performed best on pictures. Angular was the worst performing framework on the majority of the criteria. React performed best if all results are added together. For web applications that handle images, Vue is recommended to be used in other cases, React is recommended.

Software development can be a difficult and time consuming task. In addition, producing good code is even more difficult. Poor design and implementation choices in software code can result in an end product that is both difficult to understand and difficult to maintain. A collective name for implementation and design choices that is considered to have a negative impact or indicate something negative in software code is Code smells. In this study, we identify 34 unique code smells through a systematic literature study. The results are then ranked and validated with interviews with people who work or have worked with Javascript in a professional environment at some point during the past five years. The end result is a ranked list of 32 code smells that are applicable to Javascript. The result shows that the five highest ranked code smells are Variable name conflict in closures, Depth, Argument Type Mismatch, Duplicated code and Excessive global Variables.

The goal of this investigation has been to answer the questions “Which graphs should be used to display a special type of information?”, “What information does a company need to know that a server has gone down?” and “How should the layout of the developed program look to be called easy to understand and nice to use?”. The investigation was helped by the use of user-interviews and information that was collected during meetings. Part of the work was also the development of a prototype of a so called “dashboard” where functions where tested. These tests were then used to find out if the information was showed in a suitable manner. The information gained from these earlier tests has then been compiled into a result which shows that it is important to use y-over time graphs to show information over time. Fraction based information such as pro- cents are best showed with a filling graph, such as the speedometer graph. The second question was easily answered with a simple questionnaire. The result of this questionnaire showed that it was important for companies to know how much of the servers resources was used and how much data that was sent and received. Regarding the last question, the only notable result was the fact that the UI of the prototype was to light. This resulted in a color change for the UI to the darker spectrum. / Målet med denna undersökning har varit att besvara frågorna ”vilka grafer kan användas för att visa en speciell typ av information?”,”vilken information be- höver ett företag veta för att fastslå att en server är nere?” samt ”hur ska det utvecklade systemet vara upplagt för att vara enkelt att förstå samt trevligt att använda?”. Undersökningen har utförts med hjälp av användarintervjuer samt information som insamlats under möten. Utöver denna information så har också en prototyp av en så kallad ”dashboard” skapats där grafer samt funktioner som föreslagits undersökts för att återge om informationen samt funktionerna på gränssnittet visas på ett bra sätt. Denna information har då sammanställts till ett resultat som visar att det är viktigt att återvisa information över tid som gra- fer samt procentuell information med hjälp av en fyllande graf, då kanske en hastighetsmätargraf. Den andra frågan svarades enkelt på med hjälp av ett frågeformulär. Detta gav då som resultat att det var viktigt att se resursanvänd- ning på servrarna samt hur mycket information som skickas och mottages. Det- ta implementerades sedan i systemet. I de tidigare nämnda intervjuerna fram- kom det också att det var bra om systemet inte var ljust färgat då detta gjorde så att användarna blev enkelt distraherade av gränssnittet. På grund av detta så ändrades alla färger mot det mörkare spektrumet.

JavaScript frameworks have become a rapidly growing and changing industry which led to the process of choosing a suitable framework becoming increasingly difficult. This is what this project address, it takes three of the most popular frameworks and compare them concerning three aspects; performance, modularity and usability to determine the most suitable one for a modern single-page application. The purpose was to be able to give a well-founded recommendation on which framework would be most suited for a given project. To determine which framework is most suitable, three of the most popular frameworks are considered: Angular, React and Vue. These are often referred to as the big three when it comes to JavaScript frameworks and hints at the fact that they are by far the most popular frameworks. By developing and deploying a modern single-page application with a focus on the front-end in each of the frameworks and performing tests in regards to the three aspects performance, modularity and usability test data could be measured and compared. The comparison was performed by evaluating the test results of the three aspects using a method called the analytical hierarchy process. The results show that the most suitable JavaScript framework for developing a frontend heavy single-page application would be React since it performed best in regards to performance and modularity. Vue comes in second with the most notable advantage being performing best when comparing usability since it was the framework considered to be the easiest one to learn. Angular comes in at a third place with the most notable advantage being that it was considered best at DOM-manipulation. All three frameworks are considered suitable to create a single-page application but from the perspective of this project, the most suitable would be React. Further research may be done into additional frameworks to give the study even more width. It would also be interesting to go more into depth in either of the aspects to get a more extensive analyze. / JavaScript-ramverk har blivit en snabbt växande och förändrande bransch som har innebärt att processen att välja lämpliga ramverk har blivit allt svårare. Detta är vad detta projekt försöker utreda, vi kommer att ta tre av de mest populära ramverken och jämföra dem angående tre aspekter, prestanda, modularitet och användarvänlighet för att bestämma det mest lämpliga för en modern single-page application. Syftet var att kunna ge en välgrundad rekommendation om vilket ramverk som skulle vara bäst lämpat för ett visst projekt. För att bestämma vilket ramverk som är bäst lämpat betraktas tre av de mest populära ramverken: Angular, React och Vue. Dessa benämns ofta de stora tre när det gäller JavaScript-ramverk och anknyter på att de överlägset är de mest populära ramverken. Genom att utveckla och sätta i produktion en modern single-page application med fokus på front-end i vart och ett av ramverken och utföra tester med avseende på de tre aspekterna prestanda, modularitet och användarvänlighet kan testdatan mätas och jämföras. Jämförelsen genomfördes genom att utvärdera testresultaten för de tre aspekterna med hjälp av metoden Analytic hierarchy process. Resultaten visar att det mest lämpliga JavaScript-ramverket för att utveckla en front-end tung single-page application skulle vara React eftersom det presterade bäst i aspekterna prestanda och modularitet. Vue kommer på andra plats med den mest anmärkningsvärda fördelen att den presterar bäst när man jämför användarvänlighet eftersom det var det ramverk som ansågs vara den enklaste att lära sig. Angular kommer in på en tredje-plats med den mest anmärkningsvärda fördelen att Angular ansågs bäst vid DOM-manipulation. Alla tre ramverk anses vara lämpliga för att skapa en single-page application men ur projektets perspektiv är React det mest lämpade ramverket. Vidare undersökning kan utföras i yttligare ramverk för att ge studien ytterligare bredd. Det skulle också kunna vara intressant att gå mer på djupet i någon av aspekterna för att få en mer omfattande analys.

JavaScript has in recent years become one of the most utilized programming languages for developing different kinds of applications. However, even though it has received a lot of praise for its simplicity, versatility and highly active community, it lacks some functionalities and features that a lot of programmers highly value, like static and strict typing, compile-time debugging, and to not be required to make use of third-party libraries to integrate crucial functionality. However, several new languages built on top of JavaScript have been developed to address and resolve these issues developers find with JavaScript without losing the benefits that come with it. One of these super- set languages is Reason, the new syntax and toolchain powered by the OCaml compiler. This thesis aims to address whether there are scenarios where Reason could act as a reasonable substitute of JavaScript by investigating how the languages compare in regards to different criteria. The criteria examined are writability, data structures and typing, reliability and testing, community support, market demand, portability, and performance. The findings show that using Reason over JavaScript could result in higher reliability and robustness due to static type checking, compile-time debugging, and other usable feature like pattern matching and explicitly defined custom data structures, which is convenient when dealing with advanced data. On the other hand, Reason’s interoperability with JavaScript is something that is not very straight-forward and makes it difficult to integrate Reason into an existing JavaScript codebase or include one of the thousand of JavaScript- written dependencies available on npm. Furthermore, with Reason being a rather young language yet to be used by a larger audience, both the community support and market demand are a lot smaller than that of JavaScript and have yet to see a significant growth, which leads to questions about the overall survival of the language. Both of the languages have a significant role and contribute with different kind of functionality. However, with the non-straightforward interoperability, Reason loses a lot of potential benefits to be gained from JavaScript, which could be problematic in the long run and could impact the future of Reason. / JavaScript har under senare år blivit ett av de mest använda programmeringsspråken för att utveckla olika typer av applikationer. Men även om det har fått mycket beröm för sin enkelhet, mångsidighet och mycket aktivt nätgemenskap, saknar det vissa funktioner och egenskaper som många programmerare uppskattar mycket, som statisk och strikt typning, felsökning under kompilering och att inte vara I behov av tredjepartsbibliotek för att integrera grundläggande funktionalitet. Flera nya språk som är byggda ovanpå JavaScript har utvecklats för att lösa de problem som utvecklare har med JavaScript, utan att förlora fördelarna med det. Ett av dessa supersetsspråk är Reason, den nya syntaxen och verktygskedjan som drivs av OCaml-kompilatorn. Denna avhandling syfte är att utvärdera om det finns scenarier där Reason kan fungera som en rimlig ersättare för JavaScript, detta kommer genomföras genom att undersöka hur språken jämförs med varandra med avseende på olika kriterier. Kriterierna som undersöks är skrivbarhet, datastrukturer och typning, tillförlitlighet och testning, nätgemenskap, marknadsförfrågan, portabilitet, och prestanda. Resultaten visar att användning av Reason över JavaScript kan leda till högre tillförlitlighet på grund av statisk typkontroll, felsökning under kompilering och andra användbara funktioner som mönstermatchning och anpassade datastrukturer, båda underlättar vid hantering avancerade och komplexa datastrukturer. Däremot är Reasons kompabilitet med JavaScript komplicerad, vilket gör det svårt att integrera Reason i en befintlig JavaScript- kodbas eller inkludera ett av de tusentals JavaScript-skrivna biblioteken som finns tillgängliga på npm. Eftersom Reason är ett ganska ungt språk som ännu inte används på en större skala, så är både nätgemenskapen och marknadens efterfrågan mycket mindre än JavaScript och har ännu inte sett en betydande tillväxt, vilket leder till frågor om den långsiktiga överlevnaden av språket. Båda språken har en betydande roll och bidrar med olika slags funktioner. Men med den komplicerade kompatibiliteten med JavaScript så förlorar Reason en hel del potentiella fördelar som kan uppnås genom JavaScript, vilket kan vara problematiskt på lång sikt och kan påverka Reasons framtid.

JavaScript-built programs are widely used by the general public, but they are also vulnerable to JavaScript-related exploits stemming from the newly discovered prototype pollution vulnerability. Research has been focused on understanding the impact of this vulnerability and finding ways to detect it using code analysis tools. However, current tools have difficulty achieving both high accuracy and completeness, and many do not provide out-of-thebox support for detecting prototype pollution. This creates the possibility of tools with no out-of-the-box support for the vulnerability potentially being better suited for different environments and scenarios than the currently employed state-of-the-art. This thesis aggregates the existing knowledge about prototype pollution detection and examines the detection capability of Joern, a code analysis tool that does not have out-of-the-box support for prototype pollution detection, by comparing it to the state-of-the-art tool CodeQL. The comparison is made by analyzing their ability to detect prototype pollution in vulnerable Node.js packages. Both tools use queries to analyze code. An implemented Joern query is compared to prototype pollution queries included in CodeQL, as well as a CodeQL query taken from the literature. The results show that Joern is capable of identifying prototype pollution vulnerabilities but also wrongly reports more places as vulnerable than it correctly identifies. The same issue was found with the CodeQL query taken from the literature, which also found more vulnerabilities than the implemented Joern query. However, the implemented Joern query could identify a larger number of vulnerabilities in the dataset than the included CodeQL queries. Joern’s reasons for the misclassification of code as (non)vulnerable were identified as JavaScript constructs/features not being correctly modeled, bugs in the tool, and difficulty in differentiating data structures from each other. In conclusion, Joern can be used to detect prototype pollution vulnerabilities but requires further development and research to improve its detection capability. / JavaScript-byggda program används dagligen av allmänheten, men dessa program är sårbara för olika JavaScript-relaterade angrepp möjliggjord av den nyligen upptäckta sårbarheten prototypförorening. Tidigare forskning har fokuserat på att förstå dess konsekvenser i kombination med sätt att detektera sårbarheten med hjälp av verktyg för kodanalys. Nuvarande verktyg har svårt att detektera alla sårbarheter med en hög noggrannhet, och många ger inte stöd för att detektera prototypförorening som standard. Detta skapar möjligheten för verktyg utan inbyggt stöd för sårbarheten att potentiellt vara bättre lämpade i olika miljöer och scenarier än nuvarande state-of-the-art. Denna rapport sammanfattar den befintliga kunskapen om detektion av prototypförorening och undersöker detekteringsförmågan hos Joern, ett verktyg för kodanalys som inte har inbyggt stöd för att detektera prototypförorening, genom att jämföra den med state-of-the-art-verktyget CodeQL. Jämförelsen görs genom att analysera verktygens förmåga att detektera prototypförorening i sårbara Node.js-paket. Båda verktygen använder queries för att analysera kod. En implementerad Joern-query jämförs med queries som ingår i CodeQL, samt med en CodeQL-query som hämtas från litteraturen. Resultaten visar att Joern kan identifiera prototypförorening men rapporterar även felaktigt fler platser som sårbara än den korrekt identifierar. CodeQL-queryn som hämtades från litteraturen hade samma problem, dock kunde den hitta fler sårbarheter än den implementerade Joern-queryn. Den implementerade Joern-queryn hittade istället ett större antal sårbarheter i datasetet än de queries som var inkluderade i CodeQL. Joerns anledningar för felklassificering av kodrader som (icke)sårbara identifierades som att vissa JavaScript-konstruktioner modelleras felaktigt, buggar i verktyget och svårigheter att skilja mellan datastrukturer. Sammanfattningsvis kan Joern användas för att detektera prototypförorening men kräver ytterligare utveckling och forskning för att förbättra dess detekteringsförmåga.